搜索论坛 帖子排序:  Oldest to newest Newest to oldest

2011-04-05, 09:06 上午 Memory_code 注册: 2010-02-12 发 贴: 25 看起来是死锁，但是不知道该如何调试~ 今天开了几个程序以后屏幕就不动了……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.看来是之前就有线程没有释放……可是好像找不到这个线程，接下来该怎么办呢…… IP 地址: 已记录   报告

2011-04-05, 11:08 上午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 看起来是死锁，但是不知道该如何调试~ 典型的死锁，如果需要帮忙，压缩dump后传上来或者发到哪个share drive... IP 地址: 已记录   报告

2011-04-05, 15:58 下午 Memory_code 注册: 2010-02-12 发 贴: 25 Re: 看起来是死锁，但是不知道该如何调试~ http://www.rayfile.com/files/5dc65de3-5f58-11e0-bd98-0015c55db73d/ 对不起张老师……一直没用过网盘……一些网盘又上传不了……这个连27M的东西都要用它的软件下载……我正在找看看有没有别的地方~ IP 地址: 已记录   报告

2011-04-05, 16:33 下午 Memory_code 注册: 2010-02-12 发 贴: 25 Re: 看起来是死锁，但是不知道该如何调试~ ……这个似乎可以用……直接下载…… http://www.vdisk.cn/down/index/7358952A1645 IP 地址: 已记录   报告

2011-04-06, 13:21 下午 wrong 注册: 2011-01-07 发 贴: 66 Re: 看起来是死锁，但是不知道该如何调试~ 死锁的症状是什么样的？是CPU 100%，操作没有响应嘛？ IP 地址: 已记录   报告

2011-04-06, 23:10 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 看起来是死锁，但是不知道该如何调试~ 大致看了一下，死锁主要涉及以下三个线程： 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之间死锁了，拥有对方所等待的，等待对方所拥有的... IP 地址: 已记录   报告

2011-04-10, 15:30 下午 Memory_code 注册: 2010-02-12 发 贴: 25 Re: 看起来是死锁，但是不知道该如何调试~ 很感谢张老师能抽空看一下…… 因为手机的浏览器貌似一直登录不了，所以只有今天才能回复了……事实上，今天又死锁了一次，两个线程和资源出奇地一致啊…… 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的话会蓝……唉…… IP 地址: 已记录   报告

2011-04-10, 17:31 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 看起来是死锁，但是不知道该如何调试~ 可以尝试返回编红色栈帧附近的代码 u 0xf76eb9e9 ub 0xf76eb9e9 （可能失败） 如果不能双机交互式调试，那么可以尝试产生系统完整转储（Complete dump） IP 地址: 已记录   报告

2011-04-10, 18:15 下午 Memory_code 注册: 2010-02-12 发 贴: 25 Re: 看起来是死锁，但是不知道该如何调试~ 啊……回想起以前曾经分析过一个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 真后悔…… IP 地址: 已记录   报告

2011-04-10, 19:31 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 看起来是死锁，但是不知道该如何调试~ TDL3? 没用过卡巴的专杀，但看样子是它检测出 TDL 感染了 redbook。 TDL 写的挺好的，我想把它逆成代码。只是最近比较忙只写了点 SCSIOP 和感染部分的，唉。 IP 地址: 已记录   报告

2011-04-17, 15:15 下午 Memory_code 注册: 2010-02-12 发 贴: 25 Re: 看起来是死锁，但是不知道该如何调试~ 不是TDL3吧，特征不怎么符合……而且专杀也没有叫这个名字，那些名字不都是卡巴先定义的么~ 不过我对它们的硬盘过滤比较感兴趣…… IP 地址: 已记录   报告

高端调试 » 软件调试 » Windows内核调试 » Re: 看起来是死锁，但是不知道该如何调试~

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- Windows内核调试 |- C/C++本地代码调试 |- .Net程序调试 |- 脚本程序调试 |- Java程序调试 |- Linux内核调试 |- 《程序员》杂志调试专栏 |- WinDbg |- GDB |- 远程调试 |- 调试ACPI和BIOS |- 特殊的调试任务 |- 转储分析 |- GDK7 内核探秘 |- Windows内核 |- Linux内核 系统架构 |- CPU架构 |- PCI/PCI Express架构 程序人生 |- 软件物语 |- 社区活动 |- 名人逸事 联盟论坛 |- 欢迎使用CnForums 没有银弹 |- BUG也精彩 |- 豆腐工程 |- 软件圈里十大怪 Windows Vista |- 用调试利剑剖析VISTA内幕 |- 老专家如何破解新问题 |- 我的电脑谁说了算？ |- 资源 Office开发 |- Visio 驱动程序开发 |- Windows驱动开发 |- Linux驱动开发 |- Windows CE驱动开发 用户态开发 |- Windows本地代码（native）高级开发 |- Web应用开发 |- WinFX和.Net |- Office开发 本站建设 |- 高端调试团队 |- 版面布局 |- 活动建议 |- 网站维护 64位计算 |- 64-bit Windows |- 64-bit CPU 图书 |- 《软件调试》的示例程序 |- 《软件调试》的工具 |- 《软件调试》书友 |- 《软件调试》答疑 |- 《软件调试》勘误和意见 |- 《格蠹汇编》 |- 《软件调试》第二版卷1 |- 《软件调试》第二版卷2 云计算 |- IaaS |- 云存储 |- 大数据 |- PaaS和SaaS GPU |- CUDA |- OpenCL |- HSA |- 游戏开发与调试