New IPM utility Net2SwapFlag — solves infamous KB2536487 issue
Here is a great new utility written by my colleague Jacques Bensimon.
Microsoft Knowledge Base article KB2536487, entitled Applications may crash or become unresponsive if another user logs off Remote Desktop session in Windows Server 2008 or Windows Server 2008 R2 , describes a situation whereby applications run directly from a network share can suddenly stop working for all existing and new users of a given Remote Desktop Services / Terminal Server / XenApp server as a result of one user logging off. Having butted head with this issue, I can further clarify that once all running instances of the app on that server are fully closed, the app will once again start working, … until it occurs again (the main symptom is an application crash, either immediately upon launch or later when a particular app feature is invoked). If online forum threads are any indication, this issue has been plaguing many environments for years (don’t let the recent date of that article fool you, it’s revision 5.0 and still as borderline incomprehensible as ever), and Microsoft is reported to have privately told some who’ve opened support cases that it doesn’t plan to provide a fix for this issue (because it entails a network File Control Block management strategy embedded deep within the redirector – I thought FCBs had gone out with 16-bit DOS applications, so I’m guessing Microsoft has recycled the term to denote something of a similar nature – think handle or the like).
Before I get to Microsoft’s suggested workarounds, let me first quickly dispense with a couple of urban myths that have grown up around solving the issue (I’ve tried them all, none of them work):
· Run the app directly from a UNC path rather than a mapped drive (even if the app allows it, doesn’t work).
· Make sure no mapping even exists to that share before using the UNC path (nope).
· Use a DFS share, either mapped or via UNC (nyet and nyet).
Now here are Microsoft’s suggestions (verbatim from the KB article):
1. Do not run shared applications from a mapped folder; instead install the shared application locally on the Terminal Server.
That right there is some solid technical support work! … but let’s move on.
2. Use WebDAV shares as opposed to mapped folders if remote binary sharing is required.
Not at all disruptive I’m sure (!) but, as you’d suspect, those who tried it reported horrible performance, so let’s move on again.
3. Compile the application using the “Swap run from network” linker setting. This setting is described here.
I was ready to laugh this one off as well (the main affected app being a complex network-installed third-party application for which our client obviously didn’t have the source code and the means to recompile it), but I read the description of that linker setting anyway and found out that an executable (EXE/DLL/OCX) linked with that setting is treated differently by Windows when it is loaded, i.e. it is first copied to the local swap file and loaded from that location. Well, that doesn’t sound like any kind of code change, merely some instruction to the OS about how the executable should be handled, the sort of thing one might find specified by something in the executable’s header maybe? Armed with the Microsoft PE Header Specification and the experience of previously having investigated the Terminal Server Aware Flag, also found in the PE header and the subject of the IPM TSFlag utility, I found out that this setting is indeed also a single-bit flag (officially called IMAGE_FILE_NET_RUN_FROM_SWAP, value 0x0800 in the header’s so-called Characteristics word) and that it could therefore in theory be set into an already compiled executable … and thus was born the IPM Net2SwapFlag utility:
I applied it to every executable in the application’s network folder [For %F in (*.exe *.dll *.ocx) do Net2SwapFlag-x64 %F /QY] and the app crashes have completely disappeared since. If the utility is launched interactively on one of the executables, it now displays something like
I have yet to run into an executable “in the wild” that already had that flag set, so I’m guessing not a lot of developers are even aware of the feature (which by the way as a side-effect should somewhat speed up the overall performance of network-based applications).
But there was one more piece of information provided as part of that last workaround given in the KB article:
If the application is a managed app, instead use the “Shadow Copy” feature described here.
I and a couple of .NET developers I spoke to couldn’t make any sense of that “Shadow Copy” feature for standalone apps (the linked article appears oriented to web development with ASP.Net), and it’s unclear from the KB article whether setting the magic flag in the header of a .NET executable would have the same desirable “run from swap” effect. So for now I can only present Net2SwapFlag as a working solution to the KB2536487 issue for unmanaged (i.e. non-.NET) applications. I of course would be happy to know whether it works with managed apps, one way or the other – I’m leaning 51% toward it working there as well. [If ever a utility required a disclaimer, this is it, so let’s keep it simple: You assume all the risks of using this utility, even if the resulting executables cause untold data and/or job loss! Don’t even think of using the utility otherwise. Capiche?]
Later,
Jacques.
You can find the utilities here.