问题
I have a Delph 6 DirectShow application that exchanges audio with Skype via sockets. I am getting an intermittent access violation in one of the threads started by one of the DLLs loaded by the Filter Graph when the DirectShow filter chain is ran. The DLL does not belong to me so I don't have the source code.
I have examined the Event Log and I see this relevant excerpt when the Filter Graph is ran :
Thread Start: Thread ID: $00000804. Process Test.exe ($CE4)
Module Load: QCap.dll. No Debug Info. Base Address: $757F0000. Process Test.exe ($CE4)
Thread Start: Thread ID: $00000608. Process Test.exe ($CE4)
Thread Start: Thread ID: $0000259C. Process Test.exe ($CE4)
Thread Start: Thread ID: $00002778. Process Test.exe ($CE4)
ODS: DXCHAIN, STARTING> DXCaptureFilterComponent1 succeeded Process Test.exe ($CE4)
ODS: DXCHAIN, STARTING> DXChainComp_mic2skype Process Test.exe ($CE4)
Module Load: DSOUND.dll. No Debug Info. Base Address: $73F10000. Process Test.exe ($CE4)
ODS: (TPushSourcePinBase_wavaudio.Create) Construction succeeded. Process Test.exe ($CE4)
ODS: (TPushSourcePinBase_wavaudio.Create) Construction succeeded. Process Test.exe ($CE4)
Module Load: wavdest.ax. No Debug Info. Base Address: $10000000. Process Test.exe ($CE4)
ODS: (TPushSourcePinBase_wavaudio.DecideBufferSize) Resulting buffer size for audio is: 800 Process Test.exe ($CE4)
ODS: (TPushSourcePinBase_wavaudio.DecideBufferSize) Resulting buffer size for audio is: 800 Process Test.exe ($CE4)
Thread Start: Thread ID: $000027E0. Process Test.exe ($CE4)
Thread Start: Thread ID: $00001DF0. Process Test.exe ($CE4)
Thread Start: Thread ID: $0000176C. Process Test.exe ($CE4)
Thread Start: Thread ID: $0000083C. Process Test.exe ($CE4)
Note, the ODS lines are the result of "debug print" statements to the Debug Monitor window (OutputDebugString)
The thread that threw the AV in trial documented above was $0000176C. The thread is always the 12th thread created and the location reported by the debugger for the AV is always *$77BEFOOF*. My questions are:
1) How can I tell which of the dynamically loaded DLLs owns the faulting thread?
2) Is there a way to find out the start and end memory locations for each DLL, even those that I don't have source code for, so I can see what DLL contains the $77BEF00F address location?
3) Has anyone ever had trouble with an application that mixed DirectShow chains and sockets? Any caveats or tips you can throw me? The DirectShow chains in my application mix in audio data coming in from sockets and send data to sockets.
UPDATE: Using Roman R's Process Explorer tip I have tracked the AV fault location of $77BEFOOF to msacm32.dll, which is the Microsoft Audio Compression Manager (shown as "Microsoft ACM Audio Filter" in the Process Explorer Description field.) If anyone has any field experience with problems with that DLL, please share.
回答1:
Threads don't belong to DLLs, they belong to processes. You will normally want which DLL started a thread, so you will chcek thread call stack and see what are the entries at the very bottom - this will suggest who is the thread starter.
DLL is mapped into process at certain base address, you can query this programmatically via PSAPI (e.g. EnumProcessModules), or Process Explorer can get it to you interactively (columns Base, Size).
来源：https://stackoverflow.com/questions/8310016/how-can-i-tell-what-dll-started-a-thread-and-what-address-space-a-dll-owns-for-a