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!)

18 thoughts on “crtsrv HTTP Error 500.19 – Internal Server Error 64 Bit Windows 2008

  1. 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!!

  2. 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.

  3. 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!

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

  5. 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! 😀

Leave a Reply

Your email address will not be published. Required fields are marked *