SEHException from applications on a mapped share

Question

Background

We run all our windows forms applications from a windows share (UNC) mapped locally to user's W drive. We've had connection issues the past few days and are receiving System.Runtime.InteropServices.SEHException's from somewhat random places in our programs after they have been running from several minutes to several hours.

These exceptions are thrown even after the connection has been re-established. They seem to occur when showing a dialog or other form. None of the programs are doing any disk/network i/o in user code.

Questions

Do windows forms application's delay load resources from within the exe file?

If so is there anyway to force these to load earlier? or reload them after they fail?

Any insights or suggestions on running windows forms applications from a network share? Other than the obvious "copy files to local machine" by boss doesn't like that idea.

Answer 1

I don't have compelling proof for this, but it is standard MSFT practice to use memory mapped files. There's plenty of CreateFileMapping() calls in Rotor. Very efficient for read-only files like assemblies, the memory pages don't have to be backed by the paging file.

But, it hits the fan when the Windows memory manager needs to swap pages back in and the file became inaccessible. It fits your observation very well. There's no workaround for this, other than your boss committing to his preference and purchasing more reliable networking hardware. A MTBF of hours is pretty poor.

Answer 2

If you have access to the client machines, you can open Administrative Tools and go to Microsoft .NET Framework Configuration to define a custom permission set for your application. For more information see this article at ID Automation.

In theory, you should be able to use Group Policy or similar to push this change out across the entire network if you need to, but I haven't tried it myself.

The other option is to open the Security Zones settings in Internet Explorer, and add a file:// path to the share to the Local Intranet zone so that it has greater permissions, eg: add file://servername/sharename to the Local Intranet zone.