Possible deadlock in custom applications while trying to load dll's

The problem occurs with applications while one thread is reading from the stdin and another thread which tries to load a DLL and tries to get hold of that handle (inherited).

This stack you typically see if you analyze your hang using debugging tools.

kernel32!GetFileType
comctl32!_ioinit
comctl32!_CRT_INIT
comctl32!_DllMainCRTStartup
ntdll!LdrpCallInitRoutine
ntdll!LdrpRunInitializeRoutines
ntdll!LdrpLoadDll
ntdll!LdrLoadDll

 

You can't have more than one IO (GetStdHandle counts as "IO") on the same synchronous file object. It is a race condition as to whether the child process will call GetFileType() called before the parent gets back to its ReadFile().

GetFileType() is another form of IO, just like ReadFile() and WriteFile(). This is
because the IO system just doesn't know what the file type is; it has to ask the
file system itself.

So if there is synchronous IO already pending (such as a ReadFile/Writefile) on another
thread, GetFileType() will block until that first IO completes.

There were in-depth design changes for the GetFileType implemenation in Vista, so this kind of hang will not be seen in newer Operating Systems.

 

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.