How I diagnosed en elusive ‘is not a valid Win32 application’ exception

We were using BizTalk Server 2010 and the MQ Client (MQSC) adapter from Host Integration Server 2010 (HIS 2010). We had been getting an exception on and off on servers without really knowing why it appeared on some servers and not on others. We even opened a case with Microsoft, but they are only human like the rest of us and can’t magically diagnose and solve errors remotely based on vague input, so that really didn’t lead anywhere other then things like “Make sure you are running the adapter in a 64-bit process”. The exception message was this:

The adapter "MQSC" raised an error message. 
Details "Could not load file or assembly 'Microsoft.BizTalk.Adapter.Mqsc.ImqWrapper.dll' 
or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)".

It’s enough to say that we investigated the error in a number of ways, including making sure that the specific dll mentioned was present. But as we all know the “or one of its dependencies” can hide any number of referenced dlls. So we made sure that the machines that worked and the ones that didn’t had the same assemblies available, which they did. Still no luck in narrowing it down. Luckily the exception happened right when you enabled a receive location so it was easy to identify and therefore to reproduce and troubleshoot.

I resorted to using Process Monitor (not to be confused with Process Explorer, although also a great tool not the best in this scenario). I started the tool, found the PID for the process running my MQSC adapter process (see this post for details on identifying the BTSNTSvc process that belong to a certain host and get the PID) and set a filter for just that PID to reduce the noise. Finally I enabled the receive location. That gave me this:

As you can see in the image BizTalk Server is probing for an assembly in different locations, and it’s not the Microsoft.BizTalk.Adapter.Mqsc.ImqWrapper.dll. It’s the imqb23vn.dll from the WebSphere MQ installation. It’s trying to locate the assembly and finding it in the WebSphere MQ\Bin64 folder. However it gets an Access Denied when trying to access it, so it then continues on to the WebSphere MQ\Bin folder, where it locates the 32-bit version, which is does have access to, and so it loads it.

The exception message then is not saying that a 32-bit process is trying to use an assembly meant for a 64-bit process, but the opposite; that the assembly we are trying to load cannot be loaded as the application that is loading it (in this case BTSNTSvc64.exe) is a 64-bit process, aka not a valid win32 application.

Setting the correct permission on the file and hooking onto the process once again to see what it is doing verified the theory. The image below shows how it loads the correct 64-bit version of the imqb23vn.dll and the continues on to the next assembly which has the same issue and causes the exception once again. The exact same exception, but this time caused by another underlying referenced assembly:

Setting appropriate access permissions on the entire folder made the process complete without exceptions and the adapter able to successfully connect to the MQ queue and pick up the messages on it and deliver them to the messagebox. Why the folders ended up getting different permissions in this way is still a mystery…

HTH,
/Johan