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

WordPress and Windows Server – Permission Problems

In the land of one-click installers, where any web host can get a WordPress site running with little-to-no user interaction, sometimes installing WordPress on a Windows server is an exercise in frustration.

While at it’s base level, you can use the Web Platform Installer to install WordPress but I’ve found that it is rarely that simple. With a lot of our clients, they decide that they want a blog to go with their existing non-WordPress site while keeping it on their main domain. This is understandable. I would probably want the same thing.

But what I’ve had to deal with ends up being a fight between user permissions and application permissions just to get WordPress running. While many may not have this problem, but it comes up frequently for me and for some reason I always forget what I did to resolve all my errors. So this time around, this post is not only meant to share with the world, it’s my own reminder when I have to do it again.

The issue arises when I install WordPress in a sub-folder of a parent website. This is because they usually want to be the URL, and I like keeping things organized so I am ok with this.

I usually come across two different problems, and frequently they will both show up depending on my attempts to fix it.

The first error is an actual IIS error that is thrown in regards to the web.config file not having sufficient permissions. Often this error will appear first, and then after I had what I figured was the correct permissions, I end up with the second problem.

The second one is an infinitely loading page. I could leave it for hours and it will never time out, never throw an error, but just make an attempt to load the page forever.

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

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

The most likely resolution is to make sure that your IIS_IUSRS account has read access to the folder where the web.config is located. for the parent site. While this may not seem to resolve the issue, I found that I had to stop and restart the Application Pool in order for it to recognize the changes.

Some people suggested that you actually need to give the Application Pool created by the blog proper permissions, which you can access in the permissions settings by using IIS ApplicationPool\<applicationPoolName> but I haven’t found this to be the actual problem either time I’ve run into this but it is worth noting.

Microsoft also suggests this error can be caused by a malformed applicationHost.config file but this is highly unlikely to be caused by simply installing WordPress. Especially if you have other sites running already.

Just remember not to give the IIS_IUSRS account write access. And being on Windows, the first time you try to install a plugin or update WordPress, it will most likely ask for FTP credentials as well.

It’s amazing how easily you can forget something as simple as giving proper user permissions. Cheers!

Using 32-bit DLLs on a 64-bit server

The old servers at my work used a number of DLLs that were either generated in-house or purchased/downloaded from a third-party. After upgrading our servers to 64-bit machines we still had the need to support these DLLs for the large number of sites still using code from these DLLs.

After registering the DLLs with the server, we were still having problems getting things to work properly. It just so happened that I stumbled across someone mention the issue with 32-bit DLLs on a 64-bit server and how to get IIS to support them.

Ultimately it was as simple as opening a Command Prompt (ran as Administrator of course) and using the command:

%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:true

The %windir% is ultimately just your Windows installation which will more often than not just be C:\Windows

So if you have to support older DLLs, keep this in mind as you will probably need to do this to get them to work properly.

The compiler failed with error code 1073741502

This is a fun error you may never see while working on a Windows Server. I came across the other day when I arrived at work and unfortunately I still can’t pinpoint what caused it to happen but I can talk about what I researched and what we ended up having to do to fix it.

We had a couple sites on our development server (thank goodness it wasn’t live) that started producing this error. The obvious first steps were to do things like recycle the application pool, restart the site, and even restart IIS. Some reports from people online said that this fixed their problem.

Alas I was not so lucky. The next step was to venture into C:\Windows\Microsoft.NET\Framework\ and into the appropriate framework and then into the “Temporary ASP.NET Files” and clear this folder out. In this case the sites were all running on .NET Framework v2.0.50727 but it is safe to clear out this folder anyways. The files that reside in here are just the compiled files being served up to the end-user and if they don’t exist, they are simple recompiled and served up fresh!

At first I just deleted the files being referenced in my specific error but when that didn’t fix, I just cleared the folder. Definitely not something I would do on a production server in case what happened actually happens. After I did clear out the entire temporary folder none of the sited would load and I was getting the 1073741502 error across the board.

Terrible, but it did offer a clue. None of the sites could be recompiled. Some more searching suggested that the Identity in IIS might not have sufficient permissions to run the compiler. A good thought but since this wasn’t a new server and I know it had been compiling that this wasn’t the problem (though I checked anyways for the sake of being thorough).

I then went and checked csc.exe, which happened to be the C# Compiler. Wouldn’t you know it, Windows was reporting that the file was 0 bytes in size. Ultimately we ran the .Net repair tool because it seems that our installation became corrupted. After this finished the sites worked fine, everything recompiled, and all was right in the world again.

Doing follow-ups, some people reported different ideas of what could cause it and the most prevalent one was possible hardware failing. As this is our development server only and not our back-up or production server it doesn’t always have the shiniest of hardware. We ran a back-up of everything just in case and the problem will be further investigated by the powers that be.

So if you ever come across a 1073741502 error:

  1. Restart the website in IIS
  2. Recycle the Application Pool
  3. Restart IIS
  4. Try deleting the files within the Temporary ASP.NET Files folder
  5. Be sure that if you are using a custom identity that it has proper permissions to run things like csc.exe
  6. Check for signs of a corrupted installation (files with no size, etc)

There are probably more effective ways to check this information but solid suggestions about how to handle this error were few and far between so it made for an eventful morning!