XML Receive Pipeline throwing exception: Verify the schema for this document specification is deployed and is in the Global Assembly Cache

Recently, I came across an issue, in which we saw thefollowing error:

There was a failure executing the receive pipeline:"Microsoft.BizTalk.DefaultPipelines.XMLReceive,Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler"Receive Port: "xx" URI: "xx" Reason: The document specification <ABC> from assembly <ABC, Version=3.0.0.0,
Culture=neutral, PublicKeyToken=01f1964d80eede25> failed to load. Verify theschema for this document specification is deployed and is in the Global Assembly Cache.

Usually the first troubleshooting step is to check for the error would be to verify if the schema ABC, is actually deployed and present in the GAC. The next important thing is to check if some newer version of the
schema is deployed and if BizTalk is looking for the correct schema version.

But what if everything looks to be fine. The correct version of the schema is present in the GAC. Then why are we still getting the error?
After spending lots of hours in this, we found out that this error was occurring due to a concept called Desktop Heap.

Before proceeding further, let us just briefly discuss about the desktop heap.
Every operating system has some area of memory in the kernel mode called Session space and each session represents a single user’s logon environment. Every process running under a user belongs to this session.
Every session has some memory allocated to run these processes (Session view space which contains desktop heap).

Desktop Heap – what is it, what is it used for?

Every desktop object has a single desktop heap associated with it. The desktop heap stores certain user interface objects, such as windows, menus, and hooks.  
When an application requires a user interface object, functions within user32.dll are called to allocate those objects. If an application does not depend on user32.dll, it does not consume desktop heap.

For more details on desktop heap, please visit the following URL: https://blogs.msdn.com/b/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx

So coming back to the original issue. After doing some analysis we found that at the point when the error was occurring, we were getting the following error in one of the traces:
The operation failed.
Bind result: hr = 0x8007000e. Not enough storage is available to complete this operation.

Interesting isn’t it?
We then checked the number of host instances that were configured using a particular user ZZZ\UserName1. There were around 20 host instances. When we configured the host instance (on which the given application
was deployed) with a different user/new user, we were able to resolve the error and everything seemed to work fine.

Here’s the catch! Every user is allocated some memory space which is then allocated to the process that run under that user. If a single user runs multiple processes, it may happen that there could be a process for
which not enough memory is available for allocations.

In our case, since the BTSNTSvc.exe could not load the schema into the memory as the memory heap space overflowed, so even if the schema was present in the GAC, BizTalk was not able to find it and therefore
giving out the error message: Verify the schema for this document specification is deployed and is in the Global Assembly Cache.

So next time, if you see this error and everything seems to be fine in GAC, do try to run the application or deploy the artifact under different user ad try this out.

Note: This issue will not happen with OS: Windows 2000 as there is no concept of session space.
However if you are using Windows XP or any higher version of the OS, you could find this issue.

Written by
Rasika Chaudhary

Reviewed by
Shailesh agre

Microsoft India GTSC