problems with application being launched from network drive
-
When I start an application (details below) from a mapped network drive (e.x. "Z:\software\myapplication.exe") and while working with said application the network connection is disrupted (e.x. because I pull my network cable) then after some random amount of time my application will "vanish" - no error messages, no log entries, no nothing, simply gone. Why that?!? The application is a pretty normal MFC based application made with VC++ 2003 using a couple of DLLs (MFC redistributables stuff and stuff you need to integrate a simplistic Subversion client into it) with everything being in the very same director ("Z:\software\myapplication.exe", "Z:\software\mfc71.dll", "Z:\software\intl3_svn.dll", etc.). The network drive itself is hosted on a Samba server and I am using a fully updated WindowsXP.
-
When I start an application (details below) from a mapped network drive (e.x. "Z:\software\myapplication.exe") and while working with said application the network connection is disrupted (e.x. because I pull my network cable) then after some random amount of time my application will "vanish" - no error messages, no log entries, no nothing, simply gone. Why that?!? The application is a pretty normal MFC based application made with VC++ 2003 using a couple of DLLs (MFC redistributables stuff and stuff you need to integrate a simplistic Subversion client into it) with everything being in the very same director ("Z:\software\myapplication.exe", "Z:\software\mfc71.dll", "Z:\software\intl3_svn.dll", etc.). The network drive itself is hosted on a Samba server and I am using a fully updated WindowsXP.
-
Are there any DLLs in the startup directory, or does it store any temp files there?
Silver member by constant and unflinching longevity.
In the network directory... S:\Creator ...are the following files: -- my application -- Creator.exe -- DLLs needed by MFC -- mfc71.dll msvcp71.dll msvcr71.dll -- DLLs needed by integrated Subversion client -- intl3_svn.dll libapr.dll libapriconv.dll libaprutil.dll libdb44.dll libeay32.dll ssleay32.dll -- files being read by my application during startup, but not again later -- CreatorEditRights.dat symbols.bmp symbolsme.bmp On my (local) desktop I do have a shortcut icon pointing to... S:\Creator\Creator.exe ...whereas the working directory is... S:\Creator The project data itself loaded during startup of my application are all residing in a directory on my local harddisc C: Please note: the "DLLs needed by MFC" are of course not necessary on my development machine but I put them there since all the users of my application don't necessarily have the MFC 7.1 redistributables installed. I wanted to keep it simple alias no installation required so I put the necessary DLLs right next to my application. This itself works perfectly on all the Windows XP machines here in the office. At least as long the network directory is accessible all the time...
-
In the network directory... S:\Creator ...are the following files: -- my application -- Creator.exe -- DLLs needed by MFC -- mfc71.dll msvcp71.dll msvcr71.dll -- DLLs needed by integrated Subversion client -- intl3_svn.dll libapr.dll libapriconv.dll libaprutil.dll libdb44.dll libeay32.dll ssleay32.dll -- files being read by my application during startup, but not again later -- CreatorEditRights.dat symbols.bmp symbolsme.bmp On my (local) desktop I do have a shortcut icon pointing to... S:\Creator\Creator.exe ...whereas the working directory is... S:\Creator The project data itself loaded during startup of my application are all residing in a directory on my local harddisc C: Please note: the "DLLs needed by MFC" are of course not necessary on my development machine but I put them there since all the users of my application don't necessarily have the MFC 7.1 redistributables installed. I wanted to keep it simple alias no installation required so I put the necessary DLLs right next to my application. This itself works perfectly on all the Windows XP machines here in the office. At least as long the network directory is accessible all the time...
T.T.H. wrote:
This itself works perfectly on all the Windows XP machines here in the office. At least as long the network directory is accessible all the time...
Exactly. I suspect it dies when it is trying to load another dll from the local directory, either originally, or when it swaps in and out. If this is in c++, I would put a try catch around the event loop, and show message with what ever is coming back. I suspect it is an uncaught exception when a dll fails to load. Or possibly another part of the app? I'm assuming you have the source, otherwise, you are going to have to create a simple install. Either that, or be willing to take the hit when the network goes down. I suspect that there will be so many other screams that this one will just raise the noise level slightly. RM
Silver member by constant and unflinching longevity.
-
T.T.H. wrote:
This itself works perfectly on all the Windows XP machines here in the office. At least as long the network directory is accessible all the time...
Exactly. I suspect it dies when it is trying to load another dll from the local directory, either originally, or when it swaps in and out. If this is in c++, I would put a try catch around the event loop, and show message with what ever is coming back. I suspect it is an uncaught exception when a dll fails to load. Or possibly another part of the app? I'm assuming you have the source, otherwise, you are going to have to create a simple install. Either that, or be willing to take the hit when the network goes down. I suspect that there will be so many other screams that this one will just raise the noise level slightly. RM
Silver member by constant and unflinching longevity.
I do have the source code (it's "my" application after all) and there already is a big try/catch block around the Run() function:
int CCreatorApp::Run() { try { // run the application ReturnValue = CWinApp::Run(); } ((( lot of different catches here, including catch(...) )))Unfortunately it never triggers (in the case where the network is gone). In addition when there would be an unhandled exception my operation system should tell me "hey, there had been an unhandled exception" (that default message box) - which does not trigger, too. The problem being caused by trying to load a DLL sounds reasonable - but a) how can I find out that this is actually the cause (does Windows have any log files for such events?) and b) how to prevent it (e.x. preloading all DDLs) ? Regarding local installations: the huuuge advantage of the "exe in network share" solution is the fact that I can update the application (which happens quite often, like once every week) and everybody is instantly working with the new version. Users are lazy and the last thing I need is them whining over bugs which would not have happened with the most current version of the application. The whole thing ran fine the last three years, with a random, at that point unexplainable crash every half year or so, but since our network router has a hickup and the networking going occasionally away it's really became an annoyance, with "loss of work" and all such nasty things. P.S.: thanks for your help, is really appreciated! -
I do have the source code (it's "my" application after all) and there already is a big try/catch block around the Run() function:
int CCreatorApp::Run() { try { // run the application ReturnValue = CWinApp::Run(); } ((( lot of different catches here, including catch(...) )))Unfortunately it never triggers (in the case where the network is gone). In addition when there would be an unhandled exception my operation system should tell me "hey, there had been an unhandled exception" (that default message box) - which does not trigger, too. The problem being caused by trying to load a DLL sounds reasonable - but a) how can I find out that this is actually the cause (does Windows have any log files for such events?) and b) how to prevent it (e.x. preloading all DDLs) ? Regarding local installations: the huuuge advantage of the "exe in network share" solution is the fact that I can update the application (which happens quite often, like once every week) and everybody is instantly working with the new version. Users are lazy and the last thing I need is them whining over bugs which would not have happened with the most current version of the application. The whole thing ran fine the last three years, with a random, at that point unexplainable crash every half year or so, but since our network router has a hickup and the networking going occasionally away it's really became an annoyance, with "loss of work" and all such nasty things. P.S.: thanks for your help, is really appreciated!There are two sides to the dll problem - YOUR dlls, and 'system' dlls. Your dlls are part of your app, they are compiled from code you write, and that you could change. System DLLs are like the MFC DLLs, that will not change unless you change your development environment. Move the system dlls to the local systems, so they are always available. Keep your dlls & executable on the network, but, like you said, force load them. It's been years since I've done VC++/non- managed, so I don't remember any system calls for loading DLLs. Top of my head, put a 'known' method in each of the dlls (like '
void LoadGrahicsDLL();' in graphics.dll). Spin off a thread that calls each of them after a minute or so, so it is not directly affecting your load time. I know there are also ways to force the dll to load by name. This link may help, and there are other CodeProject DLL loading articles as well. Delayed DLL Loading[^] I have not looked at this in detail, but it is C++, not sure if managed or not. Another thing you could do is to make a directory in temp or even 'program files', and copy any dlls there when you load, and than force load the dlls from there. In affect, installing on the fly. I guess you could even take this to the extreme, and have a small program that is the one the users think they are loading that makes sure the local copy is correct and starts the real (local) program. You just have to figure out a way to keep them from figuring out that is the real app and running it directly. This leads to all kinds of testing scenarios to determine what would die, and at what stage it would. All of this to say that no, now I'm not sure how to catch the exception, or if there even is an exception available to catch. I remember that we used to have a similar problem with a local net deployed app (during testing), and just wrote it off as a cost of having network deployment. I don't recall that we did or did not get a log entry. We just told the test team that of course it would die if the exe came across the network, and they pulled the network cable out. :rolleyes:Silver member by constant and unflinching longevity.
-
When I start an application (details below) from a mapped network drive (e.x. "Z:\software\myapplication.exe") and while working with said application the network connection is disrupted (e.x. because I pull my network cable) then after some random amount of time my application will "vanish" - no error messages, no log entries, no nothing, simply gone. Why that?!? The application is a pretty normal MFC based application made with VC++ 2003 using a couple of DLLs (MFC redistributables stuff and stuff you need to integrate a simplistic Subversion client into it) with everything being in the very same director ("Z:\software\myapplication.exe", "Z:\software\mfc71.dll", "Z:\software\intl3_svn.dll", etc.). The network drive itself is hosted on a Samba server and I am using a fully updated WindowsXP.
Windows is a demand-paged operating system. It only reads pages from executables as they are referenced. If the OS has lost contact with the file system that the executable came from, when a new page that hasn't been used before (or was discarded because it hadn't been used recently) is referenced, an error may occur. If it does, Windows cannot continue executing the process and so kills it. There are linker flags which you can use to tell the linker to mark the executable so that the OS reads the whole file into the swap file before beginning execution. Use
/SWAPRUN:NETto mark for network execution and/SWAPRUN:CDto mark for removable disks such as CD-ROM. You can useeditbinto mark the executable after linking."Multithreading is just one damn thing after, before, or simultaneous with another." - Andrei Alexandrescu
-
Windows is a demand-paged operating system. It only reads pages from executables as they are referenced. If the OS has lost contact with the file system that the executable came from, when a new page that hasn't been used before (or was discarded because it hadn't been used recently) is referenced, an error may occur. If it does, Windows cannot continue executing the process and so kills it. There are linker flags which you can use to tell the linker to mark the executable so that the OS reads the whole file into the swap file before beginning execution. Use
/SWAPRUN:NETto mark for network execution and/SWAPRUN:CDto mark for removable disks such as CD-ROM. You can useeditbinto mark the executable after linking."Multithreading is just one damn thing after, before, or simultaneous with another." - Andrei Alexandrescu