locked
Program crashes on startup, but works when moved to another folder. RRS feed

  • General discussion

  • I've got a whacky situation that I can't seem to figure out.  We have a distributed client/server application written in C# using .Net 2.0.  It runs fine...for days, for weeks, everything is pee-chee.  This is on Windows XP Pro, SP2, btw.  Then, suddenly, one day, the application won't run.  It crashes on startup.  I can't even begin to debug it because it seems the system has crashed the application before the client entry point.

     

    The application will fail to run indefinitely.  Until...get this...until I move the program to another directory.  Without rebuilding the application, without changing the .config files, without doing anything to the actual bits or configuration of the application, simply moving the assemblies to another folder (or more practically, simply renaming the parent folder) is sufficient to allow the application to start up and run again.

     

    The users are running the application under a "Limited User" account.  I suspect this to be an important tidbit of information.  And, as far as I can tell, all the permissions are set properly.  Nothing, as far as I can tell, changes wrt the folder/system permissions.  Even if I create a new folder with the same name/path as the crashing scenario, and reset all the permissions, etc. the application simply won't run.  If I just rename the last folder in the path to the application, then it will run again.

     

    This smells like some sort of whacky permissions/security thing, or something.  But, I can't figure out why it will run for a period of time, and then suddenly stop.  Nor, can I figure out how to get the application to run again unless I rename the parent folder that houses the application assemblies.

     

    Help?

     

    Thanks,

    -tedvz

    Thursday, June 28, 2007 12:36 AM

All replies

  • Whacky indeed.  It is impossible to guess what is going on without some kind of exception info.  Look in the event log with Control Panel + Administrative tools + Events.
    Thursday, June 28, 2007 11:37 AM
  • Interestingly the problem happened again today.  I've not always been able to figure out the circumstances leading up to the problem.  But, today the exact same thing happened after we had a sudden power outtage.  (FWIW, I currently live/work in the jungles/mountains of Papua, Indonesia - this is definitely 3rd world where power is very inconsistent.)  Anyway, the computer was no properly shut down, and upon reboot, we got the same exception and the program wouldn't run.  I renamed the directory that the EXE assembly is in from "...\GudangMgrApp\ProgramFiles" to "...\GudangMgrApp\Program Files" and everything ran smoothly from there.  Later, when this happens again, I'll simply remove the space in the path between "Program Files" and it'll start running again.

     

    I did check the Event log.  It didn't seem too helpful.  There were basically two sets of errors:

     

    Event Type: Error
    Event Source: .NET Runtime 2.0 Error Reporting
    Event Category: None
    Event ID: 5000
    Date:  6/27/2007
    Time:  5:06:49 AM
    User:  N/A
    Computer: GUDANG-DESK
    Description:
    EventType clr20r3, P1 gudangmgrapp.exe, P2 1.1.706.2201, P3 467b0938, P4 system.configuration, P5 2.0.0.0, P6 4333ae78, P7 1a4, P8 4d, P9 ioibmurhynrxkw0zxkyrvfn0boyyufow, P10 NIL.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    Data:
    0000: 63 00 6c 00 72 00 32 00   c.l.r.2.
    0008: 30 00 72 00 33 00 2c 00   0.r.3.,.
    0010: 20 00 67 00 75 00 64 00    .g.u.d.
    0018: 61 00 6e 00 67 00 6d 00   a.n.g.m.
    0020: 67 00 72 00 61 00 70 00   g.r.a.p.
    0028: 70 00 2e 00 65 00 78 00   p...e.x.
    0030: 65 00 2c 00 20 00 31 00   e.,. .1.
    0038: 2e 00 31 00 2e 00 37 00   ..1...7.
    0040: 30 00 36 00 2e 00 32 00   0.6...2.
    0048: 32 00 30 00 31 00 2c 00   2.0.1.,.
    0050: 20 00 34 00 36 00 37 00    .4.6.7.
    0058: 62 00 30 00 39 00 33 00   b.0.9.3.
    0060: 38 00 2c 00 20 00 73 00   8.,. .s.
    0068: 79 00 73 00 74 00 65 00   y.s.t.e.
    0070: 6d 00 2e 00 63 00 6f 00   m...c.o.
    0078: 6e 00 66 00 69 00 67 00   n.f.i.g.
    0080: 75 00 72 00 61 00 74 00   u.r.a.t.
    0088: 69 00 6f 00 6e 00 2c 00   i.o.n.,.
    0090: 20 00 32 00 2e 00 30 00    .2...0.
    0098: 2e 00 30 00 2e 00 30 00   ..0...0.
    00a0: 2c 00 20 00 34 00 33 00   ,. .4.3.
    00a8: 33 00 33 00 61 00 65 00   3.3.a.e.
    00b0: 37 00 38 00 2c 00 20 00   7.8.,. .
    00b8: 31 00 61 00 34 00 2c 00   1.a.4.,.
    00c0: 20 00 34 00 64 00 2c 00    .4.d.,.
    00c8: 20 00 69 00 6f 00 69 00    .i.o.i.
    00d0: 62 00 6d 00 75 00 72 00   b.m.u.r.
    00d8: 68 00 79 00 6e 00 72 00   h.y.n.r.
    00e0: 78 00 6b 00 77 00 30 00   x.k.w.0.
    00e8: 7a 00 78 00 6b 00 79 00   z.x.k.y.
    00f0: 72 00 76 00 66 00 6e 00   r.v.f.n.
    00f8: 30 00 62 00 6f 00 79 00   0.b.o.y.
    0100: 79 00 75 00 66 00 6f 00   y.u.f.o.
    0108: 77 00 20 00 4e 00 49 00   w. .N.I.
    0110: 4c 00 0d 00 0a 00         L..... 

     

    the second one:

     

    Event Type: Information
    Event Source: .NET Runtime 2.0 Error Reporting
    Event Category: None
    Event ID: 5001
    Date:  7/3/2007
    Time:  9:12:28 AM
    User:  N/A
    Computer: GUDANG-DESK
    Description:
    Bucket 53598728, bucket table 5, EventType clr20r3, P1 gudangmgrapp.exe, P2 1.1.706.2901, P3 46844f14, P4 system.configuration, P5 2.0.0.0, P6 4333ae78, P7 1a4, P8 4d, P9 ioibmurhynrxkw0zxkyrvfn0boyyufow, P10 NIL.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    Data:
    0000: 42 00 75 00 63 00 6b 00   B.u.c.k.
    0008: 65 00 74 00 3a 00 20 00   e.t.:. .
    0010: 35 00 33 00 35 00 39 00   5.3.5.9.
    0018: 38 00 37 00 32 00 38 00   8.7.2.8.
    0020: 0d 00 0a 00 42 00 75 00   ....B.u.
    0028: 63 00 6b 00 65 00 74 00   c.k.e.t.
    0030: 54 00 61 00 62 00 6c 00   T.a.b.l.
    0038: 65 00 20 00 35 00 0d 00   e. .5...
    0040: 0a 00                     ..     

     

    When the problem occured earlier, I tried to copy the "Error Report" that I went ahead and sent to Microsoft.  But, the contents of the error report could not be copied from the dialog that shows the information.  Is there any way to get more complete info from the exception to paste in here?

     

    This problem is really annoying, and basically requires a Sys Admin to be around full-time.  Because if the power fails again, and there isn't a user nearby to shut the machine off, the UPS eventually runs out of juice and the system suddenly is turned off.  Afterwards, it seems, we can run into the situation whereby the EXE won't run anymore until the directory/path name leading up to the EXE is changed.

     

    How can I provide more useful information to this forum so this problem can be more appropriately diagnosed?

     

    Thanks for your help in advance.

     

    -tedvz

     

    Tuesday, July 3, 2007 12:56 AM
  • No other leads, thoughts or suggestions on this weird problem?
    Monday, July 9, 2007 3:31 AM
  • I would guess it has to do with the <yourApp>.exe.config file because I can reproduce this error consistently by moving or renaming the exe.config file and I get the exact same .net runtime error at startup.
    This is a serious limitation because I went through the trouble of reverting to the built in application settings manager instead of the custom one I wrote.
    I wanted to test what would happen if the user inadvertently deleted or corrupted the exe.config file and boom! My custom method for handling settings was a lot more robust as it simply created a new default setting file if it encountered any problems.
    Let me know if I'm spot on or a mile off.
    Thanks
    Tuesday, July 24, 2007 10:39 AM
  • We have encountered EXACTLY the same problem.

    We had a working program in the program files directory that just stopped working one day, with no other known change to the system.

    We found that by renaming any part of the executables file path (the file name, any directory component in the path) will cause the program to work. Returning the path to the original path causes it to fail again.

    We even loaded the application in a new directory and tested it and it worked. Then we swapped names on the directories so that the new exe file had the old file path. And the new exe file stopped working.

    We have run virus scans, Check Disk scans, rebooted to no avail.

    Has anybody ever solved this problem?
    Wednesday, May 27, 2009 6:00 PM
  • Sounds like a corrupted user configuration file to me.  It is stored in an isolated directory whose name is created from a hash.  I think the program name and directory is part of the hash.  Renaming the program would generate a different hash, thus a different location of the configuration file.

    Hans Passant.
    Wednesday, May 27, 2009 7:06 PM
  • I've been having this same issue with a WinForms service we created in .NET 2.0

    It can only stay running for about 30 seconds before Dr. Watson kicks in and it crashes... Once I move the SAME file to another folder and reregister it, it runs fine!?

    Any news on this issue? I would love to find the root cause of why this service (program) can't run in it's original folder in some rare cases,
    we have a product used by thousands of customers and so far we have seen this issue on about 20 different PC's and can't reproduce it in our lab.

    Any Help would be great... Thanks
    • Edited by xghoulx Wednesday, September 30, 2009 11:11 PM verbiage
    Wednesday, September 30, 2009 7:23 PM
  • That's it!
    Thank you very much!

    Just deleting the user configuration folder helps.

    This strange thing bugged me for a looong time.

    My question now is: How can I prevent it?

    Thursday, April 18, 2013 6:31 AM
  • I too having the same issue.

    Did you find a way to prevent it?

    Wednesday, February 24, 2016 6:30 AM
  • I am having this exact same problem, were you ever able to find a solution?

    Thanks

    Monday, May 6, 2019 5:27 PM
  • Were you ever able to find a solution to this problem?
    Monday, May 6, 2019 5:28 PM