我怎么知道什么DLL启动一个线程，一个DLL拥有一个外部DLL的地址空间？

本文介绍了我怎么知道什么DLL启动一个线程，一个DLL拥有一个外部DLL的地址空间？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个Delph 6 DirectShow应用程序通过插座与Skype交换音频。当DirectShow过滤器链被运行时，我在由Filter Graph加载的一个DLL启动的线程之一中间接访问冲突。该DLL不属于我，所以我没有源代码。

我已经检查了事件日志，当过滤器图运行时，我看到这个相关的摘录：

 线程开始：线程ID：$ 00000804。 Process Test.exe（$ CE4）
模块加载：QCap.dll。没有调试信息基地址：$ 757F0000。 Process Test.exe（$ CE4）
线程开始：线程ID：$ 00000608。 Process Test.exe（$ CE4）
线程开始：线程ID：$ 0000259C。 Process Test.exe（$ CE4）
线程开始：线程ID：$ 00002778。 Process Test.exe（$ CE4）
 ODS：DXCHAIN，STARTING> DXCaptureFilterComponent1成功进程Test.exe（$ CE4）
 ODS：DXCHAIN，STARTING> DXChainComp_mic2skype进程Test.exe（$ CE4）
模块加载：DSOUND.dll。没有调试信息基地址：$ 73F10000。 Process Test.exe（$ CE4）
 ODS：（TPushSourcePinBase_wavaudio.Create）构建成功。 Process Test.exe（$ CE4）
 ODS：（TPushSourcePinBase_wavaudio.Create）构建成功。 Process Test.exe（$ CE4）
模块加载：wavdest.ax。没有调试信息基地址：$ 10000000。 Process Test.exe（$ CE4）
 ODS：（TPushSourcePinBase_wavaudio.DecideBufferSize）音频的最终缓冲区大小为：800 Process Test.exe（$ CE4）
 ODS：（TPushSourcePinBase_wavaudio.DecideBufferSize）音频是：800 Process Test.exe（$ CE4）
线程开始：线程ID：$ 000027E0。 Process Test.exe（$ CE4）
线程开始：线程ID：$ 00001DF0。 Process Test.exe（$ CE4）
线程开始：线程ID：$ 0000176C。 Process Test.exe（$ CE4）
线程开始：线程ID：$ 0000083C。 Process Test.exe（$ CE4）

注意，ODS行是调试打印调试监视器窗口的声明（OutputDebugString）

上面提到的试用AV的线程是$ 0000176C。线程始终第12个线程创建，调试器为AV报告的位置是始终 * $ 77BEFOOF *。我的问题是：

1）如何知道哪个动态加载的DLL拥有故障线程？

2）有没有办法找出每个DLL的开始和结束内存位置，即使那些我没有源代码，所以我可以看到什么DLL包含 $ 77BEF00F 地址位置？

3）有没有人遇到过混合DirectShow链和套接字的应用程序的麻烦？任何可以扔我的警告或提示？我的应用程序中的DirectShow链结合来自插座的音频数据，并将数据发送到套接字。

更新：使用Roman R的Process Explorer提示我已经将 $ 77BEFOOF 的AV故障位置跟踪到 msacm32.dll ，这是Microsoft Audio Compression Manager（在Process Explorer中显示为Microsoft ACM音频过滤器 em>描述字段。）如果任何人有任何现场经验与该DLL有问题，请分享。

解决方案

线程不属于DLL，它们属于进程。你通常会想要哪个DLL启动一个线程，所以你将要查询线程调用堆栈，看看底部的条目是什么 - 这将提示谁是线程启动器。

DLL映射到进程在某个基地址，您可以通过 PSAPI （例如）或可以交互地获取它（列 Base ， Size ）。

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.

解决方案

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).

这篇关于我怎么知道什么DLL启动一个线程，一个DLL拥有一个外部DLL的地址空间？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！