Our application is a hybrid Win32 unmanaged application and a .NET 2.0 managed application. The Win32 part is the main executable, which at some point loads and hosts the .NET 2.0 runtime and loads some managed modules to open new winforms windows.
We’ve had our share of CASPOL-type problems, but today we have a very odd problem and I’m hoping someone can give me some pointers or ideas, or basically just anything really, that would trigger a spark of something that would help us resolve this.
On a server, accessed through citrix, if the application files are located in a directory located on the desktop of the currently logged on user, which is a server/domain administrator, the program runs fine. The .NET windows open as expected.
However, if we move the directory to the root of the same disk, which is a physical disk in the server (so no SAN mapping or anything that would trigger a CASPOL command to my knowledge) and keep everything else the same, same user, same configuration, etc., the application silently crashes when we try to invoke the .NET windows. It crashes by way of just disappearing, which suggests it might be something like a stack overflow. We’re looking into adding logging to some parts of the app to perhaps be able to figure out what happens, and where, but I’m posting this question here as well.
So far we’ve verified that there are no oddities in the CASPOL access list, nothing odd in the NGEN cache (I was thinking perhaps there was corrupted images from before, if the server owner had played with it), and no oddities in the GAC (we don’t use GAC for the assemblies).
Summarized:
- If the program is run from U:\Documents and Settings\USERNAME\Desktop\directory, it works
- If it is run from U:\directory, it doesn’t
- U: is a physical disk in the server
- No apparent oddities in NGEN or GAC caches
- The right .NET runtime is installed, the right files for our application has been installed (and indeed work fine if run from the desktop location)
Anyone with anything that might help?
Edit: Problem re-asked here with different/other information, and ‘solved’.
My first stab would be to run process monitor from MS-Sysinternals, and look what calls/results are different for these two occasions. Maybe that would give you some hints to work on (different results for the same call, some errors in the problem run that are not in the good one…)
You can download process monitor from MS: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx