crtsrv HTTP Error 500.19 – Internal Server Error 64 Bit Windows 2008

When accessing the newly configured /CRTSRV service on a windows 2008 server, we were thrown the following error.

HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

Module CustomErrorModule
Notification SendResponse
Handler Not yet determined
Error Code 0x80070003
Config Error Cannot read configuration file 
Config File \\?\C:\Windows\system32\CertSrv\en-US\web.config
Requested URL
Physical Path C:\Windows\system32\CertSrv\en-US\certfnsh.asp
Logon Method Not yet determined
Logon User Not yet determined

Browsing to the directory showed that:

Config File \\?\C:\Windows\system32\CertSrv\en-US\web.config

File is missing or does not exist.

This was somewhat frustrating because it was a fresh instance of Windows 2008 server and the service had just been added and configured without error.

The long and short of it all for us was that it related to the fact that the server was a 64 bit server, and in IIS by default, 32 bit applications are enabled.

To fix the problem we started IIS.

Browsed to the Application Pools and ensured that the application pool for the CRTSRV service had “Enable 32-Bit Applications” set to False


This made the site come alive!

(Can’t help but comment how sucky it is that this does not just work out of the box. Even if I cut MS some slack and acknowledge how many variables are in place for this type of configuration, it still SUCKS that the status error code thrown is as good as meaningless! – This is why I hate MS more and more every day!)

Posted by InteractiveWebs

This blog is the combined blog work of the InteractiveWebs Dev Team. Together we work on a range of DotNetNuke (DNN) applications, modules, Silverlight, and Microsoft CRM Portal integration products. Our Business is website design and hosting, with a strong focus on DotNetNuke, Microsoft Dynamics CRM, Silverlight and iPhone iPad development.


Thanks for this post, I’ve spent quite some time searching – who would have thought that the ‘enable 32-bit applications’ flag would kill certsrv!!

thank you very much
took a while to find this…but sure glad I did


Glad it helped.

Thanks it helped a lot



Thanks, head scratcher!!


No problemo

Thank you so much, this problem ‘ll kill me if i don’t find your article.
Once again thanks you

Note also that your Default Web Site physical path must be “wwwroot” (ie.- C:\inetpub\wwwroot).

Just fyi, it seems to also work if you create a .net 4.0 integrated app pool with “allow 32bit apps” disabled. .net 2.0 doesn’t seem to be required for it.


Interesting comment. Not sure why the path must be the wwwroot? Would it not work the same on any path on the server with the correct permissions set?

I had this problem with RPC over HTTP working for Exchange 2010 on a 2008 R2 server. I disabled 32bit applications for the defaultapppool and it fixed the problem. After doing searches relating to Exchange, I couldn’t find anything to fix my problem. Excluded Exchange from the search and I luckily found this. Goes to show you that you must think far outside the box when troubleshooting MS products. Thank you very much!


Thanks for the notes.

Thanks a lot for your article!

I have spent numerous hours researching this, have addressed ACL and appPools multiple times to no avail,


You are welcome. If you blog, please back link to this.

Thanks so much for sharing your solution to this annoying problem. I too was working on a freshly installed, fully patched WS08R2 system and was baffled as to why the default configurations weren’t working. Now I can move forward! 😀


You are welcome!


It work for me to change the Application pool to 32Bit .

thank you

Leave a Reply