Why Does My .Net Application Crash When Run from a Network Drive

Why does my .NET application crash when run from a network drive?

It indeed has to do with the fact the apps on a network location are less trusted then on your local hdd (due to the default policy of the .NET framework).

If I'm not mistaken Microsoft finally corrected this annoyance in .NET 3.5 SP1 (after a lot of developers complaining).

I google'd it: .NET Framework 3.5 SP1 Allows managed code to be launched from a network share!

Starting .NET application from network share with extern DLL runs into crash

This sounds like a "caspol" issue. Network shares like \\localhost\program\ get reduced trust. Interestingly, from (some time ago), named shares actually get more trust - so one simple option is to map, say, z: as \\localhost\program, and access z:\prog.exe - you might find that this makes it work. Beyond that, the options are:

• caspol changes to the each client machine
• ClickOnce

of those, the latter is simpler. Then you simply run the ClickOnce application (rather than the .exe) - ClickOnce then basically makes it work. The user will, IIRC, need to click an "ok" the first time they run the application, but that's about it. You would need to ensure that the external dll is known the the ClickOnce deployment, i.e. it is in the project and marked to be shipped.

My .net application works on local machine but fails when used from a network location

These threads will answer you question, I think:

• Why does my .NET application crash when run from a network drive?
• Running a C# exe file

This behaviour is changed in .NET Framework 3.5 SP1, where it defaults to allowing programs running off network shares.

And yes, it does not feel very practical, but there is unfortunately not much to do about that...

Performance penalties for .NET app running from shared network folder

When running an executable over the network, Windows does not bring the entire application over the network at application startup. This is done to speed startup times (and there's no point is downloading that 700MB embedded AVI resource if you never actually use it).

This means that periodically, as new pages from the executable image are required, Windows will go back to the network to retrieve them.

The method in which this is accomplished is that if your application happens to hit a page of memory that is not present, a standard page fault will trigger, telling Windows it needs to fill that page. If the network happens to be down at that moment, Windows will be unable to satisfy the page-fault. There's no way to recover from this, so Windows throws an EXCEPTION_IN_PAGE_ERROR (0xC0000005).

There are three ways to handle this:

• do nothing and let the application die. Tell the customer to fix their network
• trap the error, explaining that the application must be terminated now, and telling the user that their network is to blame
• set the IMAGE_FILE_NET_RUN_FROM_SWAP PE image option. This will instruct Windows to copy the entire executable over the network at application load time. This will increase network traffic and user wait times (at application launch time), but avoid the error

Running a .NET application from a file share without code signing

Using CasPol to Fully Trust a Share

more answers here:

Why does my .NET application crash when run from a network drive?

Application deployment to network drive

My question for you is why would you want to? Why not just publish the .NET application using click once to the network share?

When you run the application from the network share, a copy of the program is loaded into memory on the client machine, and requests for supporting files will transverse the network as well, to be loaded into memory. On top of this, you have to check for any prerequisites, and may experience some failures.

If you publish to the network share, when you complete the publish wizard, your browser will open up to a webpage that resides on the network share. Just share the URL to this and users will be able to 'install' the program on their machine. Best part about this way is updates are automatic and you don't have to worry about interrupting users workflow when publishing updates.

ClickOnce applications do not require admin permissions to install, and will install its own shortcuts for the users. I have built and deployed several of these, and most users are comfortable enough with the install process to access it through a link from an email.

EDIT

You can also distribute a shortcut to the .application file once you deploy, as long as you are confident users have the pre-reqs installed. This will launch the application if it was installed, or install and then launch.

File won't run from command prompt that is on network drive

Which directory are you running the script from?

You might have to chdir to the S: drive:

import subprocess
import os

os.chdir("S:")
subprocess.call(['S:\file.exe'])

---

Related Topics