Skip to main content
added 341 characters in body
Source Link
TristanK
  • 9.2k
  • 2
  • 30
  • 39

BecauseMost likely, because one or more of the components used by your application are 32-bit.

Or, because one or more components used by your application are not found when you toggle the App Pool mode, because of their bitness, and file system redirection.

Generally speaking, IIS will divide up Modules and Handlers into 32- and 64-bit binaries, and prevent one bitness or another from seeing the other bitness with the bitness32 or bitness64 preconditions.

Top-of-head example:

<modules> <module name="something" path="c:\program files\something.dll" precondition="bitness64"> </modules>

If you change the app pool to 32 bit, keep in mind:

  • bitness64 won't be true
  • 64 bit apps aren't lied to about file locations; 32 bit apps might be (Program Files (x86), or System32 (which redirects to SysWow64))

the same module/handler might have an entry like this:

<modules> <module name="something32" path="c:\program files\something32.dll" precondition="bitness32"> </modules>

Which will only work if something32.dll is in Program files (x86).

The event logs should help you track down which module is being problematic, if it's a module or handler load failure.

If your modules or handlers don't specify a bitness precondition, and might use different paths when run from a different bitness due to redirection, you've got your problem. (the event logs will typically point you at what failed to load when an App Pool won't start).

See also:

Because one or more of the components used by your application are 32-bit.

Or, because one or more components used by your application are not found when you toggle the App Pool mode.

Generally speaking, IIS will divide up Modules and Handlers into 32- and 64-bit binaries, and prevent one bitness or another from seeing the other bitness with the bitness32 or bitness64 preconditions.

Top-of-head example:

<modules> <module name="something" path="c:\program files\something.dll" precondition="bitness64"> </modules>

If you change the app pool to 32 bit, keep in mind:

  • bitness64 won't be true
  • 64 bit apps aren't lied to about file locations; 32 bit apps might be (Program Files (x86), or System32 (which redirects to SysWow64))

the same module/handler might have an entry like this:

<modules> <module name="something32" path="c:\program files\something32.dll" precondition="bitness32"> </modules>

Which will only work if something32.dll is in Program files (x86).

The event logs should help you track down which module is being problematic, if it's a module or handler load failure.

See also:

Most likely, because one or more of the components used by your application are 32-bit.

Or, because one or more components used by your application are not found when you toggle the App Pool mode, because of their bitness, and file system redirection.

Generally speaking, IIS will divide up Modules and Handlers into 32- and 64-bit binaries, and prevent one bitness or another from seeing the other bitness with the bitness32 or bitness64 preconditions.

Top-of-head example:

<modules> <module name="something" path="c:\program files\something.dll" precondition="bitness64"> </modules>

If you change the app pool to 32 bit, keep in mind:

  • bitness64 won't be true
  • 64 bit apps aren't lied to about file locations; 32 bit apps might be (Program Files (x86), or System32 (which redirects to SysWow64))

the same module/handler might have an entry like this:

<modules> <module name="something32" path="c:\program files\something32.dll" precondition="bitness32"> </modules>

Which will only work if something32.dll is in Program files (x86).

The event logs should help you track down which module is being problematic, if it's a module or handler load failure.

If your modules or handlers don't specify a bitness precondition, and might use different paths when run from a different bitness due to redirection, you've got your problem. (the event logs will typically point you at what failed to load when an App Pool won't start).

See also:

Source Link
TristanK
  • 9.2k
  • 2
  • 30
  • 39

Because one or more of the components used by your application are 32-bit.

Or, because one or more components used by your application are not found when you toggle the App Pool mode.

Generally speaking, IIS will divide up Modules and Handlers into 32- and 64-bit binaries, and prevent one bitness or another from seeing the other bitness with the bitness32 or bitness64 preconditions.

Top-of-head example:

<modules> <module name="something" path="c:\program files\something.dll" precondition="bitness64"> </modules>

If you change the app pool to 32 bit, keep in mind:

  • bitness64 won't be true
  • 64 bit apps aren't lied to about file locations; 32 bit apps might be (Program Files (x86), or System32 (which redirects to SysWow64))

the same module/handler might have an entry like this:

<modules> <module name="something32" path="c:\program files\something32.dll" precondition="bitness32"> </modules>

Which will only work if something32.dll is in Program files (x86).

The event logs should help you track down which module is being problematic, if it's a module or handler load failure.

See also: