0

I'm configuring IIS7.5 on a new 64bit server to handle a older website that uses few 32bit components and a MS Access database.

I've set successfully the application pool to support the 32bit - so that Jet4.0 and the old components are working correctly.

However, IIS is working in a odd way: when the application pool is enabled with the 32bit flag, and an error occurs (I tried to induce a division by zero error, therefore a 500 error, and a 404 not found), it doesn't show any error page, but only a totally empty, blank page.

If the 500 error happens, let's say, in the middle of the script execution, the scripts shows its output until the error occurs and then silently stops. The website is configured to use the default IIS error pages, so there is no custom setup for the error pages.

This strange behaviour does not take place if the application pool 32bit is disabled. In this case, everything works normally.

I have made some searchs on google and I've seen that this problem was experienced by other persons but I could not find any solution yet.

89c3b1b8-b1ae-11e6-b842-48d705
  • 1,465
  • 1
  • 13
  • 22
Max Meloni
  • 1

1 Answers1

0

I have find the solution by myself, I want to share it with the community:

  • The problem is caused by the option "Enable Server-side Debugging" in the ASP/Debugging feature of the website properties. If the option is set to "True", IIS does not show any error at all, blank page. Setting it to "False", the errors are shown as usual.

This behaviour takes place only if the applicationpool is 32bit enabled. If 32bit is disabled, the error is shown even with the "Enable Server-side Debugging" set to True. Evidently there is an issue with the error messages handling between 32bit applicationpools on 64bit server.

Max Meloni
  • 1