Re: 看起来是死锁，但是不知道该如何调试~

Windows内核调试

看起来是死锁，但是不知道该如何调试~

---

Memory_code 2011-04-05, 09:06 上午
今天开了几个程序以后屏幕就不动了……Ctrl+scroll lock ……不停按不同用各种节奏按，难道要看人品？按了很久才触发……

Use !analyze -v to get detailed debugging information.

BugCheck E2, {0, 0, 0, 0}

Probably caused by : i8042prt.sys ( i8042prt!I8xProcessCrashDump+237 )

Followup: MachineOwner
---------

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

MANUALLY_INITIATED_CRASH (e2)
The user manually initiated this crash dump.
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------


BUGCHECK_STR:  MANUALLY_INITIATED_CRASH

DEFAULT_BUCKET_ID:  DRIVER_FAULT

PROCESS_NAME:  Idle

LAST_CONTROL_TRANSFER:  from f76b97fb to 80534806

STACK_TEXT: 
80551e38 f76b97fb 000000e2 00000000 00000000 nt!KeBugCheckEx+0x1b
80551e54 f76b9033 0083a9b8 01a6f1c6 00000000 i8042prt!I8xProcessCrashDump+0x237
80551e9c 804db915 89484d98 8983a900 00010009 i8042prt!I8042KeyboardInterruptService+0x21c
80551e9c f76a9162 89484d98 8983a900 00010009 nt!KiInterruptDispatch+0x3d
80551f50 804dcb37 00000000 0000000e 00000000 intelppm!AcpiC1Idle+0x12
80551f54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x10


刚刚看到一个帖子，死锁用!locks试试……
kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks..

Resource @ nt!PpRegistryDeviceResource (0x80559e00)    Exclusively owned
    Contention Count = 2
     Threads: 898f23c8-01<*>
KD: Scanning for held locks..

Resource @ nt!CmpRegistryLock (0x80558ee0)    Exclusively owned
    Contention Count = 329
    NumberOfSharedWaiters = 16
    NumberOfExclusiveWaiters = 6
     Threads: 881fd020-01<*> 886d1da8-01    882c9998-01    88b31da8-01   
              88675020-01    898f2640-01    898f2b30-01    885a1020-01   
              8868ada8-01    886996f0-01    88c2e610-01    8943f9d8-01   
              887a5140-01    88ed3da8-01    8880e520-01    898f23c8-01   
              88758870-01   
     Threads Waiting On Exclusive Access:
              888aca18       8855a588       89047938       88fd3da8      
              882c3280       884d8188      

KD: Scanning for held locks...

Resource @ nt!IopDeviceTreeLock (0x8055a260)    Shared 1 owning threads
     Threads: 898f23c8-01<*>
KD: Scanning for held locks.

Resource @ nt!PiEngineLock (0x8055a1e0)    Exclusively owned
    Contention Count = 1
     Threads: 898f23c8-01<*>
KD: Scanning for held locks..

Resource @ Ntfs!NtfsData (0xf7b72190)    Shared 1 owning threads
     Threads: 898f33c8-01<*>
KD: Scanning for held locks.

Resource @ 0x8987a514    Exclusively owned
    Contention Count = 9586
    NumberOfSharedWaiters = 29
     Threads: 88655798-02<*> 884b45b0-01    88696890-01    881f96d8-01   
              88763ba8-01    8887c800-01    898f3b30-01    8876abb0-01   
              881fc328-01    888c6bb8-01    898f38b8-01    88477ba0-01   
              881fd020-01    887e0998-01    884335a8-01    883799c8-01   
              88b894e0-01    88234020-01    883c5da8-01    886c4800-01   
              8852a8b8-01    882c89c0-01    881f9020-01    88601860-01   
              88605ba0-01    88694da8-01    88826da8-01    898f33c8-01   
              882c4720-01    885f1da8-01   
KD: Scanning for held locks.


看来应该和 8987a514 和 CmpRegistryLock有关系？

后来用!locks -v 看了一下 CmpRegistryLock的貌似是因为这个线程先是获取了Lock以后又 NtfsAcquireSharedVcb 引起的

     THREAD 881fd020  Cid 0f90.0728  Teb: 7ffdf000 Win32Thread: e11bf5a8 WAIT: (Executive) KernelMode Non-Alertable
         898d8270  Semaphore Limit 0x7fffffff
         881fd110  NotificationTimer
     IRP List:
         88166008: (0006,01fc) Flags: 00000834  Mdl: 00000000
     Not impersonating
     DeviceMap                 e1b83008
     Owning Process            0       Image:         <Unknown>
     Attached Process          88206da0       Image:         QQPYWizard.exe
     Wait Start TickCount      52611          Ticks: 12 (0:00:00:00.187)
     Context Switch Count      428                 LargeStack
     UserTime                  00:00:00.000
     KernelTime                00:00:00.093
     Win32 Start Address 0x004f304a
     Start Address 0x7c810705
     Stack Init ae4c1000 Current ae4c06e8 Base ae4c1000 Limit ae4bd000 Call 0
     Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16
     ChildEBP RetAddr 
     ae4c0700 804dd0f7 nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
     ae4c070c 804dd143 nt!KiSwapThread+0x46 (FPO: [0,0,0])
     ae4c0734 805179f9 nt!KeWaitForSingleObject+0x1c2 (FPO: [5,5,4])
     ae4c0770 804f1c20 nt!ExpWaitForResource+0xd2 (FPO: [0,5,0])
     ae4c0784 f7b728ae nt!ExAcquireResourceSharedLite+0xb2 (FPO: [2,0,4])
     ae4c0798 f7ba91cc Ntfs!NtfsAcquireSharedVcb+0x23 (FPO: [3,0,4])
     ae4c07fc f7b55b3b Ntfs!NtfsCommonSetInformation+0x28a (FPO: [Non-Fpo])
     ae4c0864 804e47f7 Ntfs!NtfsFsdSetInformation+0xa3 (FPO: [Non-Fpo])
     ae4c0874 f743ef45 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
     ae4c0888 804e47f7 sr!SrSetInformation+0x179 (FPO: [2,0,0])
     ae4c0898 f7446e9b nt!IopfCallDriver+0x31 (FPO: [0,0,0])
     ae4c08bc f744706b fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b (FPO: [3,4,4])
     ae4c08f4 804e47f7 fltMgr!FltpDispatch+0x11f (FPO: [2,6,0])
     ae4c0904 b1c949ae nt!IopfCallDriver+0x31 (FPO: [0,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
     ae4c097c 804e47f7 qutmdrv+0xc9ae
     ae4c098c 8058c0f1 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
     ae4c0a3c f747f01f nt!NtSetInformationFile+0x585 (FPO: [Non-Fpo])
     ae4c0a90 804de84d safemon+0x401f
     ae4c0b00 8058c1af nt!ZwSetInformationFile+0x11 (FPO: [5,0,0])
     ae4c0b40 8058cc47 nt!CmpDoFileSetSize+0x5e (FPO: [4,6,4])
     ae4c0b58 8058cc10 nt!CmpFileSetSize+0x16 (FPO: [4,0,0])
     ae4c0b78 8058cc59 nt!HvpGrowLog1+0x52 (FPO: [2,0,0])
     ae4c0b94 8057a415 nt!HvMarkDirty+0x19d (FPO: [4,0,4])
     ae4c0bb8 80595f0d nt!HvMarkCellDirty+0xbc (FPO: [2,0,4])
     ae4c0bd8 80595fdf nt!CmpMarkKeyDirty+0x40 (FPO: [2,1,4])
     ae4c0bf0 805960ff nt!CmpFreeKeyByCell+0x14 (FPO: [3,0,0])
     ae4c0c20 80596377 nt!CmDeleteKey+0x8c (FPO: [1,4,4])
     ae4c0c80 f747f529 nt!NtDeleteKey+0x138 (FPO: [Non-Fpo])
     ae4c0d58 804df7ec safemon+0x4529
     ae4c0d58 7c92e514 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ ae4c0d64)

其他的进程貌似都是等在NtfsAcquireSharedVcb里面，这个函数，看了一下描述：This routine acquires shared access to the Vcb.看来是之前就有线程没有释放……可是好像找不到这个线程，接下来该怎么办呢……

Re: 看起来是死锁，但是不知道该如何调试~

---

格蠹老雷 2011-04-05, 11:08 上午
典型的死锁，如果需要帮忙，压缩dump后传上来或者发到哪个share drive...

Re: 看起来是死锁，但是不知道该如何调试~

---

Memory_code 2011-04-05, 15:58 下午
http://www.rayfile.com/files/5dc65de3-5f58-11e0-bd98-0015c55db73d/

对不起张老师……一直没用过网盘……一些网盘又上传不了……这个连27M的东西都要用它的软件下载……我正在找看看有没有别的地方~

Re: 看起来是死锁，但是不知道该如何调试~

---

Memory_code 2011-04-05, 16:33 下午
……这个似乎可以用……直接下载……

http://www.vdisk.cn/down/index/7358952A1645

Re: 看起来是死锁，但是不知道该如何调试~

---

wrong 2011-04-06, 13:21 下午
死锁的症状是什么样的？是CPU 100%，操作没有响应嘛？

Re: 看起来是死锁，但是不知道该如何调试~

---

格蠹老雷 2011-04-06, 23:10 下午
大致看了一下，死锁主要涉及以下三个线程：
A：QQPYWizard.exe进程的881fd020线程：
拥有CmpRegistryLock，等待系统卷VCB的EResource（8987a514）

B：360rp.exe进程的88655798线程：
拥有系统卷VCB的EResource（8987a514），等待文件系统的另一个EResource（887138c8）

C：系统进程的898f38b8线程：
拥有360rp在等待的887138c8，等待360rp拥有的VCB EResource（8987a514）

B和C之间死锁了，拥有对方所等待的，等待对方所拥有的...

Re: 看起来是死锁，但是不知道该如何调试~

---

Memory_code 2011-04-10, 15:30 下午
很感谢张老师能抽空看一下……

因为手机的浏览器貌似一直登录不了，所以只有今天才能回复了……事实上，今天又死锁了一次，两个线程和资源出奇地一致啊……

898f38b8
的栈回溯可以看到：
kd> kvn 100
 # ChildEBP RetAddr  Args to Child             
00 f78b5e48 804dd0f7 898f3928 898f38b8 804dd143 nt!KiSwapContext+0x2e (FPO: [Uses EBP] [0,0,4])
01 f78b5e54 804dd143 00000000 8987a514 898f38b8 nt!KiSwapThread+0x46 (FPO: [0,0,0])
02 f78b5e7c 805179f9 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2 (FPO: [5,5,4])
03 f78b5eb8 804f1c20 f78b6150 f78b5fbc f78b5fbc nt!ExpWaitForResource+0xd2 (FPO: [0,5,0])
04 f78b5ecc f7b728ae 8987a514 00000001 00000009 nt!ExAcquireResourceSharedLite+0xb2 (FPO: [2,0,4])
05 f78b5ee0 f7b7ecab f78b5fbc 8987a100 00000001 Ntfs!NtfsAcquireSharedVcb+0x23 (FPO: [3,0,4])
06 f78b5f44 f7b7849c f78b5fbc 8877f1d0 893a8b68 Ntfs!NtfsCommonQueryInformation+0xd2 (FPO: [Non-Fpo])
07 f78b5fa8 f7b784d5 f78b5fbc 8877f1d0 00000001 Ntfs!NtfsFsdDispatchSwitch+0x12a (FPO: [Non-Fpo])
08 f78b60cc 804e47f7 8987a020 8877f1d0 898b1250 Ntfs!NtfsFsdDispatchWait+0x1c (FPO: [2,68,0])
09 f78b60dc f7431459 f78b6120 804e47f7 89871020 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
0a f78b60e4 804e47f7 89871020 8877f1d0 8877f1d0 sr!SrPassThrough+0x31 (FPO: [2,0,0])
0b f78b60f4 f744709e 881dd5a8 898b1030 8877f1d0 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
0c f78b6120 804e47f7 893a8b68 8877f1d0 89440f38 fltMgr!FltpDispatch+0x152 (FPO: [2,6,0])
0d f78b6130 b1c884db f78b639c 804e47f7 89424ef8 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
0e f78b6138 804e47f7 89424ef8 8877f1d0 8877f3a8 qutmdrv+0x4db
0f f78b615c f7b53c27 0110070a 00000000 00000000 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
10 f78b639c f76eb9e9 88872738 888727f0 898b9f18 Ntfs!NtfsFsdWrite+0x16a (FPO: [Non-Fpo])
11 f78b63dc 804e47f7 897bbc50 88872738 88ecf920 0xf76eb9e9
12 f78b63ec f7657fdd 00000000 887a6a48 88ecf920 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
13 f78b6400 f7657cdc 88ecf920 898aeb70 887a6b90 CLASSPNP!SubmitTransferPacket+0x82 (FPO: [1,0,4])
14 f78b6430 f7657dcd 00010000 00010000 887a6a48 CLASSPNP!ServiceTransferRequest+0xe4 (FPO: [2,6,4])
15 f78b6454 804e47f7 898aeab8 00000000 898a3dd0 CLASSPNP!ClassReadWrite+0xff (FPO: [2,2,4])
16 f78b6464 f7717921 89876a98 887a6bb4 f78b64a0 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
17 f78b6474 804e47f7 898b0900 887a6a48 887a6bd8 PartMgr!PmReadWrite+0x95 (FPO: [2,1,4])
18 f78b6484 f74d91c6 887a6bf4 898bc560 887a6a48 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
19 f78b64a0 804e47f7 898769e0 887a6a48 887a6c18 ftdisk!FtDiskReadWrite+0x194 (FPO: [Non-Fpo])
1a f78b64b0 f7637aa7 887a6a00 8987a100 898a3428 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
1b f78b64c4 804e47f7 89877ad8 887a6a48 887a6a48 VolSnap!VolSnapWrite+0xbb (FPO: [2,0,0])
1c f78b64d4 f7b531c3 f78b68cc 887a6a48 f78b66c4 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
1d f78b64e4 f7b52d26 f78b68cc 89877a20 a56ac000 Ntfs!NtfsSingleAsync+0x6d (FPO: [7,0,0])
1e f78b66c4 f7b53a6a f78b68cc 887a6a48 e2a2c0d0 Ntfs!NtfsNonCachedIo+0x2f8 (FPO: [Non-Fpo])
1f f78b68bc f7b53c18 f78b68cc 887a6a48 0110070a Ntfs!NtfsCommonWrite+0x1943 (FPO: [Non-Fpo])
20 f78b6a30 804e47f7 8987a020 887a6a48 898b1250 Ntfs!NtfsFsdWrite+0xf3 (FPO: [Non-Fpo])
21 f78b6a40 f74313ca 00000000 88750670 f78b6a84 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
22 f78b6a50 804e47f7 89871020 887a6a48 887a6a48 sr!SrWrite+0xaa (FPO: [2,0,4])
23 f78b6a60 f7446e9b 893a8b68 887a6a48 8947bc18 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
24 f78b6a84 f744706b f78b6aa4 893a8b68 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b (FPO: [3,4,4])
25 f78b6abc 804e47f7 893a8b68 887a6a48 887a6a48 fltMgr!FltpDispatch+0x11f (FPO: [2,6,0])
26 f78b6acc b1c9452b 881dd5a8 89440f38 89424ef8 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
27 f78b6b24 804e47f7 89424ef8 887a6a48 00000000 qutmdrv+0xc52b
28 f78b6b34 804f0195 f78b6b70 f78b6d40 00000000 nt!IopfCallDriver+0x31 (FPO: [0,0,0])
29 f78b6b48 804efd5c 881dd50b f78b6b70 f78b6c04 nt!IoSynchronousPageWrite+0xaf (FPO: [5,0,4])
2a f78b6c24 804eef61 e42e9498 e42e94d8 e42e94d8 nt!MiFlushSectionInternal+0x38b (FPO: [6,45,4])
2b f78b6c60 804f0420 88244138 e42e9498 00000000 nt!MmFlushSection+0x1b5 (FPO: [5,4,0])
2c f78b6ce8 804eeda8 00010000 00000000 00000001 nt!CcFlushCache+0x386 (FPO: [4,24,4])
2d f78b6d2c 804e5f1d 898f01e0 805632c0 898f38b8 nt!CcWriteBehind+0xdc (FPO: [0,8,4])
2e f78b6d74 804e526b 898f01e0 00000000 898f38b8 nt!CcWorkerThread+0x126 (FPO: [Non-Fpo])
2f f78b6dac 8057beff 898f01e0 00000000 00000000 nt!ExpWorkerThread+0x100 (FPO: [1,8,0])
30 f78b6ddc 804f98ea 804e5196 00000000 00000000 nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
31 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

#11有个很神奇的无名地址，不清楚是否是因为它的关系或者是360的关系……还有用XueTr查关机回调的时候也有一个未知地址，可能是rootkit吧……看来要实机调试才行……不过syser要是Boot start的话会蓝……唉……

Re: 看起来是死锁，但是不知道该如何调试~

---

格蠹老雷 2011-04-10, 17:31 下午
可以尝试返回编红色栈帧附近的代码
u 0xf76eb9e9
ub 0xf76eb9e9 （可能失败）
如果不能双机交互式调试，那么可以尝试产生系统完整转储（Complete dump）

Re: 看起来是死锁，但是不知道该如何调试~

---

Memory_code 2011-04-10, 18:15 下午
啊……回想起以前曾经分析过一个TDSS的样本……跑飞过一次，下载了卡巴的专杀，杀了以后，硬盘驱动对象劫持和关机回调都不见了，可是杀之前我自己拷贝出来的那个驱动可能因为劫持的关系，拷贝出来了一个正常的驱动~~然后找不到那个样本了……唉……

  ================================================================================
2011/04/10 15:14:39.0484 2688    Scan finished
2011/04/10 15:14:39.0484 2688    ================================================================================
2011/04/10 15:14:39.0500 1264    Detected object count: 1
2011/04/10 15:17:24.0656 1264    redbook         (b29404b45f86bec759ec57037d7b9a28) C:\WINDOWS\system32\DRIVERS\redbook.sys
2011/04/10 15:17:24.0656 1264    Suspicious file (Forged): C:\WINDOWS\system32\DRIVERS\redbook.sys. Real md5: b29404b45f86bec759ec57037d7b9a28, Fake md5: 14615ebaf029cd0a7af97d10fbd900cd
2011/04/10 15:17:25.0250 1264    Backup copy found, using it..
2011/04/10 15:17:26.0625 1264    C:\WINDOWS\system32\DRIVERS\redbook.sys - will be cured after reboot
2011/04/10 15:17:26.0625 1264    Rootkit.Win32.ZAccess.c(redbook) - User select action: Cure
2011/04/10 15:17:43.0640 0620    Deinitialize success

真后悔……

Re: 看起来是死锁，但是不知道该如何调试~

---

王宇 2011-04-10, 19:31 下午
TDL3? 没用过卡巴的专杀，但看样子是它检测出 TDL 感染了 redbook。

TDL 写的挺好的，我想把它逆成代码。只是最近比较忙只写了点 SCSIOP 和感染部分的，唉。

Re: 看起来是死锁，但是不知道该如何调试~

---

Memory_code 2011-04-17, 15:15 下午
不是TDL3吧，特征不怎么符合……而且专杀也没有叫这个名字，那些名字不都是卡巴先定义的么~

不过我对它们的硬盘过滤比较感兴趣……