我如何知道哪个 DLL 启动了线程以及 DLL 为外部 DLL 拥有什么地址空间?

发布于 2024-12-18 22:43:47 字数 2184 浏览 3 评论 0原文

我有一个 Delph 6 DirectShow 应用程序,可以通过套接字与 Skype 交换音频。当 DirectShow 过滤器链运行时,我在由过滤器图加载的 DLL 之一启动的线程之一中遇到间歇性访问冲突。该DLL不属于我,所以我没有源代码。

我已经检查了事件日志,并且在运行过滤器图时看到了以下相关摘录:

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)

注意,ODS 行是“调试打印”语句到调试监视器窗口 (OutputDebugString) 的结果

记录了在试验中抛出 AV 的线程以上是 $0000176C。该线程始终是创建的第 12 个线程,调试器报告的 AV 位置是始终 *$77BEFOOF*。我的问题是:

1)如何判断哪个动态加载的 DLL 拥有故障线程?

2)有没有办法找出每个DLL的起始和结束内存位置,即使是那些我没有源代码的DLL,这样我就可以看到哪个DLL包含$77BEF00F地址位置?

3) 有没有人在使用混合 DirectShow 链和套接字的应用程序时遇到过麻烦?您可以向我提出任何警告或提示吗?我的应用程序中的 DirectShow 链混合来自套接字的音频数据并将数据发送到套接字。

更新:使用Roman R的Process Explorer提示,我已将$77BEFOOF的AV故障位置跟踪到msacm32.dll,这是Microsoft音频压缩Manager(在 Process Explorer 描述 字段中显示为“Microsoft ACM 音频过滤器”。)如果任何人有该 DLL 问题的任何现场经验,请分享。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

谁把谁当真 2024-12-25 22:43:47

线程不属于 DLL,它们属于进程。您通常会想要哪个 DLL 启动了一个线程,因此您将检查线程调用堆栈并查看最底部的条目 - 这将表明谁是线程启动者。

WinInet's Thread

DLL 被映射到进程的某个基地址,您可以通过 PSAPI 以编程方式查询它(例如 EnumProcessModules),或 Process Explorer 可以交互方式获取它(Base 列、Size 列)。

在此处输入图像描述

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.

WinInet's Thread

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

enter image description here

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文