PRB: SymInitialize() May Not Return If fInvadeProcess Is TRUE (256092)
The information in this article applies to:
- Microsoft Win32 Application Programming Interface (API), when used with:
- the operating system: Microsoft Windows NT 4.0
This article was previously published under Q256092 SYMPTOMS
On Microsoft Windows NT 4.0, the SymInitialize function does not return if the fInvadeProcess parameter is TRUE and the calling thread is responsible for handling debug events as a debugger.
RESOLUTION
The debugger application gets a handle to all the modules that are loaded in the debuggee process when a particular DEBUG_EVENT occurs. So, the debugger application should call SymInitialize with the fInvadeProcess parameter specified as FALSE; the SymLoadModule function can be explicitly called to load the symbol information. The symbol information of the debuggee process executable can be loaded with the u.CreateProcessInfo.hFile handle in the DEBUG_EVENT structure when CREATE_PROCESS_DEBUG_EVENT occurs. Similarly, the symbol information for each of the dynamic-link libraries (DLLs) that are mapped in the debuggee process can be loaded with the u.LoadDll.hFile handle in the DEBUG_EVENT structure when LOAD_DLL_DEBUG_EVENT occurs.
MORE INFORMATION
If SymInitialize is called with fInvadeProcess parameter as TRUE, DbgHelp will enumerate the loaded modules for the process specified and effectively call SymLoadModule to load symbol information. If the process handle that is specified is not the current process handle or the current process ID, the system creates a remote thread in the debuggee process and waits for the remote thread to exit for collecting the information about loaded modules.
On Windows NT 4.0, the remote thread that is created in the debuggee process is seen by the debugger application. The remote thread runs only when its corresponding CREATE_THREAD_DEBUG_EVENT is handled by the debugger application and the ContinueDebugEvent function is called on that thread. Because the debugger thread waits for SymInitialize to return, it will not be able to call WaitForDebugEvent, handle the remote CREATE_THREAD_DEBUG_EVENT, and call ContinueDebugEvent. This causes a deadlock on Windows NT 4.0. As a result, SymInitialize will not return when the function is called from a debugger thread that is responsible for handling debug events.
On Microsoft Windows 2000 and Microsoft Windows XP, the remote thread that is created is hidden from the debugger application. So, the system does not send a corresponding CREATE_THREAD_DEBUG_EVENT to be handled by the debugger application. Therefore, the SymInitialize function call returns successfully on Windows 2000 and Windows XP.
| Modification Type: | Major | Last Reviewed: | 11/3/2003 |
|---|
| Keywords: | kbAPI kbBug kbDebug kbKernBase kbprb KB256092 |
|---|
|