.NET应用程序有时会在应用程序启动时崩溃（无法访问.exe）

Question

We are currently encountering the following behaviour of our software on one of our customer computers:

---

Short version:

Our .NET applications sometimes crash instantly when being executed from a client, with the executables being located on a separate file server.

When this happens, a message in the Event Log claims that the executable couldn't be accessed. However the desktop shortcut always finds the executable.

Note that this happens to several different .NET executables.

This leads us to the following

---

Question:

How can windows always access the executable (the process is visible in task manager when it crashes) but the .NET Framwork can only sometimes access it? Note that our customer sometimes has network problems for an unknown reason.
And, more importantly, is there anything we can do to prevent the crash or at least show an own message box in such a case?

For more information, read below:

---

Detailed information:

Our C# executables are located on a virtualized file server (Windows Server 2003) and were compiled with .NET 3.5 SP1.

When trying to execute the software using a desktop/start menu shortcut from a client in the same network, the executable sometimes (around 2-5% of the number of tries) crashes, ie the user receives a "<our software> has encountered an error and needs to close" message. For reference, the client has installed .NET 3.5 SP1 as well.

Further investigation showed that the program crashes before even a single line of our code is executed (ie the main() method is never reached).

In the Windows Event Log, there are two messages, the first being relatively useless (free translation from German):

Failed application, Version 0.0.0.0, failed module unknown, Version 0.0.0.0, Failure address 0x79002c42.

The second one says something like:

Due to one of the following reasons, the file \\\\<server>\\<path to software>\\<executable>.exe cannot be accessed: There is a problem with the network connection, the drive where the file is stored respectively the disk drivers which are installed on the computer, or the drive is missing. The program <executable>.exe was closed due to this error.

[some suggestions on what to do]

More information:
Error Code: C0000008
Drive Type: 4

Now the first suggestion is to try opening the file again, as the situation is probably a temporary problem. While this "solution" works, it is not acceptable to have an application crash message, especially when one of our executables calls another one.

If you cannot answer the question(s) above directly, but you have an idea how to further investigate this, feel free to comment or answer. Note however that we are not allowed to install any kind of third party software on our customer clients or even servers. Portable Apps (more precisely software which can be copy/pasted into a single folder and which does not deploy any kind of file to anywhere outside that single folder) can be used.

Answer 1

If it was me I would firstly see if I could re-create the issue locally and completely eliminate the network. Its all about building up clues that will hopefully lead you closer to the solution. Other things that maybe worth thinking about are:

1. 32bit vs 64bit, What was the target for your compilation?
2. Is there any funky scripts running on the server?
3. Does it behave in the same manner on a different server?
4. Maybe try removing the .NET framework from the server and then re-installing it
5. Make sure that there are not any other errors in the event log from other parts of the system
6. Is there any firewall or anti-virus on the server that maybe interfering with the application
7. I would also run a memory tester on the server and possibly also chkdsk but this is just a general thing to eliminate that wouldn't hurt to do as a matter of course
8. I would even swap out the network lead (extremely unlikely its this)
9. Try putting the application on a different UNC share and see if you can re-create it from there

Process of elimination is the name of the game, even the most unlikely candidates shouldn't be overlooked.