如何确定在内核调试会话中WinDBG等待什么事件 [英] How can I work out what events are being waited for with WinDBG in a kernel debug session

查看:312
本文介绍了如何确定在内核调试会话中WinDBG等待什么事件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是WinDbg的新手,我一直在尝试调试WindowsXP的问题,该问题是客户将我的软件和某些第三方软件发送给我的,以阻止Windows注销.我已重现了该问题,并已验证仅当同时安装了我们的软件和客户软件时(尽管不一定在注销时运行),才会发生注销问题.我观察到当用户尝试注销时WM_ENDSESSION消息未到达运行的窗口,并且我知道第三方软件使用内核驱动程序.

I'm a complete WinDbg newbie and I've been trying to debug a WindowsXP problem that a customer has sent me where our software and some third party software prevent windows from logging off. I've reproduced the problem and have verified that only when our software and the customers software are both installed (although not necessarily running at logoff) does the log off problem occur. I've observed that WM_ENDSESSION messages are not reaching the running windows when the user tries to log off and I know that the third party software uses a kernel driver.

我一直在查看WinDbg中的进程,并且我知道csrss.exe通常会向所有窗口发送WM_ENDSESSION消息.当我跑步时:

I've been looking at the processes in WinDbg and I know that csrss.exe would normally send all the windows a WM_ENDSESSION message. When I ran:

!过程82356020 6

!process 82356020 6

要查看csrss.exe的堆栈,我可以看到:

To look at csrss.exe's stack I can see:

WARNING: Frame IP not in any known module. Following frames may be wrong.
        00000000 00000000 00000000 00000000 00000000 0x7c90e514

        THREAD 8246d998  Cid 0248.02a0  Teb: 7ffd7000 Win32Thread: e1627008 WAIT: (WrUserRequest) UserMode Non-Alertable
            8243d9f0  SynchronizationEvent
            81fe0390  SynchronizationEvent
        Not impersonating
        DeviceMap                 e1004450
        Owning Process            82356020       Image:         csrss.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      1813           Ticks: 20748 (0:00:05:24.187)
        Context Switch Count      3                 LargeStack
        UserTime                  00:00:00.000
        KernelTime                00:00:00.000
        Start Address 0x75b67cdf
        Stack Init f80bd000 Current f80bc9c8 Base f80bd000 Limit f80ba000 Call 0
        Priority 14 BasePriority 13 PriorityDecrement 0 DecrementCount 0
        Kernel stack not resident.
        ChildEBP RetAddr  Args to Child              
        f80bc9e0 80500ce6 00000000 8246d998 804f9af2 nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
        f80bc9ec 804f9af2 804f986e e1627008 00000000 nt!KiSwapThread+0x46 (FPO: [0,0,0])
        f80bca24 bf80a4a3 00000002 82475218 00000001 nt!KeWaitForMultipleObjects+0x284 (FPO: [Non-Fpo])
        f80bca5c bf88c0a6 00000001 82475218 00000000 win32k!xxxMsgWaitForMultipleObjects+0xb0 (FPO: [Non-Fpo])
        f80bcd30 bf87507d bf9ac0a0 00000001 f80bcd54 win32k!xxxDesktopThread+0x339 (FPO: [Non-Fpo])
        f80bcd40 bf8010fd bf9ac0a0 f80bcd64 00bcfff4 win32k!xxxCreateSystemThreads+0x6a (FPO: [Non-Fpo])
        f80bcd54 8053d648 00000000 00000022 00000000 win32k!NtUserCallOneParam+0x23 (FPO: [Non-Fpo])
        f80bcd54 7c90e514 00000000 00000022 00000000 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f80bcd64)

这个waitForMultipleObjects看起来很有趣,因为我想知道csrss.exe是否正在等待某个事件,而该事件尚未到达以允许注销.谁能告诉我我怎么知道它正在等待什么事件以便进一步调查问题?

This waitForMultipleObjects looks interesting because I'm wondering if csrss.exe is waiting on some event which isn't arriving to allow the logoff. Can anyone tell me how I might find out what event it's waiting for anything else I might do to further investigate the problem?

推荐答案

正在等待的对象就在输出中:

The objects being waited on are right there in the output:

    THREAD 8246d998  Cid 0248.02a0  Teb: 7ffd7000 Win32Thread: e1627008 WAIT: (WrUserRequest) UserMode Non-Alertable  
        8243d9f0  SynchronizationEvent  
        81fe0390  SynchronizationEvent  

我会注意到,虽然您正在查看的线程是一个普通线程,但是您所查看的几乎每个系统都会拥有它(不确定该线程的确切用途,但是我知道堆栈...有时我觉得我做这件事太久了!).

I'll note though that the thread you're looking at is a common thread, just about every system that you look at will have it (not sure what that thread is for exactly, but I recognize the stack...Sometimes I feel like I've been doing this too long!).

我还要注意,您不能一直信任堆栈中的参数.在此处查看一些详细信息: http://analyze-v.com/?p=7

I'll also note that you can't trust the parameters on the stack all of the time. See some details here: http://analyze-v.com/?p=7

-斯科特

这篇关于如何确定在内核调试会话中WinDBG等待什么事件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆