Joe Levi

Recently we started getting the following error message on our ASP.NET 2.0 web application running on IIS6.

• Exception type:
  • CryptographicException
• Exception message:
  • Padding is invalid and cannot be removed.
• Stack trace:
  • at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
  • at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
  • at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
  • at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo)
  • at System.Web.UI.Page.DecryptString(String s)
  • [...]

The application provides forms authentication as the login mechanism for the end-user.

Apparently, whilst tuning the IIS settings for the application's App Pool (we forgot to set the max CPU use) we inadvertently turned on Web Garden and increased the "Max number of worker processes" from 1 (default) to 2.

Doing this created an unhandled problem, forms authentication uses the worker process to create an encrypted login chunk in the site's cookie. The encryption is specific to the worker process (even if it's on the same box). Therefore, if your user logs in using one worker process, then is shifted to another worker process, their login (as stored in the cookie) is invalid and they are prompted with to re-authenticate (which will be valid until they are shifted from that worker process to another).

There are ways to handle this, of course, so the user can hop between worker processes (or even entirely different servers) and still maintain a valid, authenticated session. But for us, we just set the worker processes back to 1 and restarted the app pool and all was well.

You can thank me later.

If you liked this post, please be sure to subscribe to my RSS Feed.

Most multifunction printers (you know the kind, they print, they scan, they fax, they make you coffee...) use what's known as a DOT4 driver in Windows. This type of driver differs from the traditional serial "COM" and parallel "LPT" ports, and is different still than a "USB" port (though it's physically connected to your USB bus via a USB port).

In Windows Server 2003 if you're trying to remap a printer, you cannot (without a registry hack) remap a DOT4 driver (only COM, LPT, and USB).

This means that when you install a multifunction printer on a Windows 2003 machine, you should opt for the USB driver (if available), rather than the DOT4. If your printer manufacturer only supplied a DOT4 drive you must try and find the USB driver, or go with a different printer (or go for the registry hack).

A side benefit: USB drivers seem to print notably faster than DOT4 drivers for the same device (at least with the devices we tested).

You can thank me later.

If you liked this post, please be sure to subscribe to my RSS Feed.