locked
Mysterious crash RRS feed

  • Question

  • Hi All,

     

    We have a strange problem that has the whole software department stumped - hopefully someone can shed some light on it! I'm not sure whether this is the right forum because we don't have a handle on the cause.

     

    We have a .NET application, written in C# 2005. This application loads a WIN32 DLL written in C++ by a 3rd party, which in turn calls another WIN32 DLL written in C++ by us (the URL of our DLL is passed to the 3rd party DLL which uses it to perform a download to a car).

     

    On startup and before the c# main function is reached, a thread is created that almost immediately suspends. Presumably this is something to do with the .NET CLR. This thread appears to stay in the thread list of the main process for a couple of minutes but when it terminates it performs an UnloadLibrary on our C++ DLL, normally during a download and with catastrophic effects! However, if we wait long enough at startup for this mystery thread to finish, everything works fine.

     

    I have used Process Explorer to examine this thread. This reports the start address for the thread as:

    ole32.dll!StringFromGUID2+0x627

     

    The call stack for the thread (oldest at the top) looks like this:

    0 ntkrnlpa.exe!ExAllocatePoolWithTag+0x96b

    1 ntkrnlpa.exe!MmlsDriverVerifying+0xa30

    2 ntkrnlpa.exe!MmlsDriverVerifying+0x1312

    3 ntkrnlpa.exe!DeRegisterLogonProcess+0x6ce9

    4 ntkrnlpa.exe!KeSynchroniseExecution+0x16c

    5 ntdll.dll!FastSystemCallRet

    6 KERNEL32.dll!Sleep+0xf

    7 ole32.dll!StringFromGUID2+0x51b

    8 KERNEL32.dll!GetModuleFileNameA+0x1b4

     

    Does anybody have any idea what the cause might be?

     

    Thanks in advance for your help.

    Richard Burke

    Wednesday, February 20, 2008 9:14 AM

Answers

  • Thanks for responding.

     

    After much debugging I think we finally have an answer.

     

    The problem was down to the 3rd party DLL. In the DllMain function, we think they are responding to a DLL_THREAD_DETACH request by unloading our DLL! In the .NET world, it appears that threads are created and destroyed fairly regularly and the DllMain function gets the DLL_THREAD_ATTACH and DLL_THREAD_DETACH requests when this happens. The DLL should only be unloaded in response to a DLL_PROCESS_DETACH request.

     

    Effectively, every time a thread ended, our program would crash because the DLL had been unloaded. It just happened that the thread I identified happened to be the first to end.

     

    I now know a lot more about how DLLs work and how to debug them!!!

    Thursday, February 21, 2008 11:05 AM

All replies

  • To troubleshoot this issue, we really need the source code and the detailed repro steps to reproduce the problem, so that we can investigate the issue in house. It is not necessary that you send out the complete source of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business logic from it.


    You can send a sample project and repro steps in details to may email address which can be found in my personal profile page.

    Thursday, February 21, 2008 2:55 AM
  • Thanks for responding.

     

    After much debugging I think we finally have an answer.

     

    The problem was down to the 3rd party DLL. In the DllMain function, we think they are responding to a DLL_THREAD_DETACH request by unloading our DLL! In the .NET world, it appears that threads are created and destroyed fairly regularly and the DllMain function gets the DLL_THREAD_ATTACH and DLL_THREAD_DETACH requests when this happens. The DLL should only be unloaded in response to a DLL_PROCESS_DETACH request.

     

    Effectively, every time a thread ended, our program would crash because the DLL had been unloaded. It just happened that the thread I identified happened to be the first to end.

     

    I now know a lot more about how DLLs work and how to debug them!!!

    Thursday, February 21, 2008 11:05 AM
  • I have had this issue when pumping large files to USB HD. After, I went back to device manager to check and USB HD policy was to optimize disconnections... so, no cache.
    Monday, April 6, 2009 11:48 AM