Windbg内核调试之五: 一次利用Dump文件调试Deadlock的实战

最近遇到项目的一个bug,安装产品之后系统hang住。大致的现象是系统logon之后,Taskbar显示,然后hang住,Ctrl+Alt+Del不能调出TaskManager,Mouse不能移动,硬盘LED不闪烁。由于机器不在手边,远程调试又极其慢(实际上是国外的机器),所以只好请求对方手动触发一个蓝屏(有关手动触发蓝屏的方式,请参考: http://msdn.microsoft.com/en-us/library/cc266483.aspx),得到一个完全dump文件(有关完全dump文件的设置,请参考: Windbg内核调试之四: Dump文件分析),利用该dump文件分析系统hang住时刻的状态。
注:这个事例中,利用Ctrl+Scroll Lock+Scroll Lock手动触发蓝屏,此键盘消息可以响应。

祭起windbg,Open Crash Dump:
Symbol search path  is : srv * c:\symbols * http: // msdl.microsoft.com/download/symbols;E:\Win7.Symbols
Executable search path  is
Windows  7  Kernel Version  7201  MP ( 2  procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by:  7201.0 .x86fre.winmain_win7ids. 090601 - 1516
Kernel  base   =   0x8363e000  PsLoadedModuleList  =   0x83786810
Debug session time: Thu Aug   6   17 : 04 : 40.745   2009  (GMT + 8 )
System Uptime:  0  days  0 : 09 : 38.352
Loading Kernel Symbols............................................................................................................
Loading User Symbols
Loading unloaded module list.....................................................................................................

系统是Window 7的RC版本7201,运行在x86系统上。
先analyze –v一下,看看调试器给定的信息是否可用:
0 : 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:
------------------
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:   0xE2
PROCESS_NAME:  System
CURRENT_IRQL:   2
LAST_CONTROL_TRANSFER:  from 9066a1aa to 8371ac88

STACK_TEXT:  
837649e4 9066a1aa 000000e2  00000000   00000000  nt ! KeBugCheckEx + 0x1e
83764a0c 9066a2ba 88a60b48 000000c6  00000000  kbdhid ! KbdHidProcessCrashDump + 0x1e2
83764a30 8de20d50  00000001  83764a4c 000000c6 kbdhid ! KbdHid_InsertCodesIntoQueue + 0x88
83764a44 8de20edd 000000c6  00000000  9066a232 HIDPARSE ! HidP_KbdPutKey + 0x30
83764a68 8de20dbd 8de216a8  00000009  9066a232 HIDPARSE ! HidP_ModifierCode + 0x81
83764a8c 8de210c0  00000047   00000000  88a56890 HIDPARSE ! HidP_TranslateUsage + 0x61
83764abc 9066a50f 88a5692d 0000000e  00000000  HIDPARSE ! HidP_TranslateUsageAndPagesToI8042ScanCodes+0x66
83764aec 836a6ab3  00000000  014b49d0  00000000  kbdhid ! KbdHid_ReadComplete + 0x18d
83764b34 8de0e424 83764b3c 83764b3c  88883020  nt ! IopfCompleteRequest + 0x128
83764b50 8de0e5df  02883008  88a28508  00000009  HIDCLASS ! HidpDistributeInterruptReport + 0xce
83764b8c 836a6ab3  00000000  8838c060 88a56de4 HIDCLASS ! HidpInterruptReadComplete + 0x1a7
83764bd0  92753868  8367e474 8902a6e0  00000000  nt ! IopfCompleteRequest + 0x128
83764c00  92754178  89147d70 8838c060 88c82b28 USBPORT ! USBPORT_Core_iCompleteDoneTransfer + 0x6e0
83764c2c 927579af 8683c028 8683c0f0 8683ca98 USBPORT ! USBPORT_Core_iIrpCsqCompleteDoneTransfer + 0x33b
83764c54 92751d18 8683c028 8683ca98 8683c002 USBPORT ! USBPORT_Core_UsbIocDpc_Worker + 0xbc
83764c78 836a6335 8683caa4 8683c002  00000000  USBPORT ! USBPORT_Xdpc_Worker + 0x173
83764cd4 836a6198 83767d20  83771280   00000000  nt ! KiExecuteAllDpcs + 0xf9
83764d20 836a5fb8  00000000  0000000e  00000000  nt ! KiRetireDpcList + 0xd5
83764d24  00000000  0000000e  00000000   00000000  nt ! KiIdleLoop + 0x38

STACK_COMMAND:  kb

FOLLOWUP_IP: 
kbdhid ! KbdHidProcessCrashDump + 1e2
9066a1aa 837d1000        cmp     dword ptr [ebp + 10h], 0

SYMBOL_STACK_INDEX:   1
SYMBOL_NAME:  kbdhid ! KbdHidProcessCrashDump + 1e2
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: kbdhid
IMAGE_NAME:  kbdhid.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  4a2487af
FAILURE_BUCKET_ID:  0xE2_kbdhid ! KbdHidProcessCrashDump + 1e2
BUCKET_ID:  0xE2_kbdhid ! KbdHidProcessCrashDump + 1e2
Followup: MachineOwner
---------

给出的信息似乎并不充分,只是针对目标系统蓝屏的一些信息,并不是想要的系统如果hang住的分析。看看进程列表:
0 : kd >   ! process  0   0
****  NT ACTIVE PROCESS DUMP  ****
PROCESS 85f22920  SessionId: none  Cid:  0004     Peb:  00000000   ParentCid:  0000
    DirBase:  00185000   ObjectTable: 8cc01c58  HandleCount:  2369 .
    Image: System
PROCESS 86c568a0  SessionId: none  Cid:  0178     Peb: 7ffdf000  ParentCid:  0004
    DirBase: b9c6d020  ObjectTable: 8cd97f30  HandleCount:   31 .
    Image: smss.exe
PROCESS 884de8f0  SessionId:  0   Cid:  0210     Peb: 7ffdd000  ParentCid: 01c4
    DirBase: b9c6d060  ObjectTable: 8cc0ab68  HandleCount:  721 .
    Image: csrss.exe
............

进程太多就没全列出来。死锁有两种情况,一种是系统死锁,像本例一样,系统没有任何响应,这种死锁多由内核驱动引起,调试相对困难,也不易找到到底是哪个进程中的线程引发死锁,哪个进程中的线程持有资源;另一种是应用程序引发的死锁,这种情况系统多数是可以响应的,鼠标或桌面,只是某个应用程序hang住,也许是TaskManager,也许是其它应用程序。这种问题相对系统级死锁要简单的多,只要attach到hang住的应用程序上,一般都可排查出问题所在,多数情况下都是应用程序进程中的某个线程持有Critical Section,引起其它线程等待资源;另一种情况是并不是多个线程的相互等待,而是线程自旋无法继续执行。所以,判断应用程序的挂死,最有效的方法就是观察CPU的使用率(Ctrl+Alt+Del),看是否达到峰值或为0。
系统级死锁不容易找到引起问题的进程,需要关注的System、 Csrss.exe、Service.exe这样比较重要的进程;应用程序死锁则重点关注applicaton本身就可以了。
本例明显是系统级的死锁,基本可以肯定是第三方驱动程序导致。进程列表是看不出什么可疑的原因的。既然怀疑是死锁的问题,运行一下!locks(!kdext*.locks,Kernal级)看看当前系统持有的锁:
0 : kd >   ! locks
****  DUMP OF ALL RESOURCE OBJECTS  ****
KD: Scanning  for  held locks.
Resource @ nt ! PnpRegistryDeviceResource ( 0x 837a3e80 )    Exclusively owned
    Contention Count  =   48
    NumberOfExclusiveWaiters  =   3
     Threads: 85f55688 - 01 <*>  
     Threads Waiting On Exclusive Access:
              85f59798       85f59a70       8893cd48       

KD: Scanning  for  held locks..................
Resource @  0x87b286dc      Shared  12  owning threads
     Threads:  89484568 - 02 <*>  88c5d030 - 03 <*>  88c5a7e0 - 02 <*>  88c5b030 - 02 <*>  
              88c5cd48 - 02 <*>  88c5c2f8 - 02 <*>  88f858f8 - 02 <*>  88df7030 - 02 <*>  
              8932ab08 - 02 <*>  889e4d48 - 02 <*>  88afa3e8 - 02 <*>  8936bd48 - 02 <*>  
KD: Scanning  for  held locks........................................................................................................
17099  total locks,  2  locks currently held

当前两个锁被持有,其中一个为 Exclusively owned ,另一个是共享锁。第一个锁为 Exclusively owned 访问,即专有访问,这种锁往往是引起死锁问题的原因。死锁的一种情况是由于系统正在执行的一个线程需要一个锁,而这个锁被当前系统未执行的某个线程所持有。系统中大部分是共享锁。
注意到第一个锁当前持有的线程为 85f55688 - 01 <*> (-01<*>代表当前持有的进程),等待队列中有三个线程在等待这个锁;第二个锁为共享锁,所有线程列表中的thread都持有它。
这两个锁实际上是两个resource的形式给出,通过命令看一下这两个resouce的结构:
0 : kd >  dt nt ! _ERESOURCE -b 0x837a 3e80
   
+ 0x000  SystemResourcesList : _LIST_ENTRY [  0x8377f3c0   -   0x8377eac0  ]
      
+ 0x000  Flink            :  0x8377f3c0  
      
+ 0x004  Blink            :  0x8377eac0  
   
+ 0x008  OwnerTable       :  0x87bfb068  
   
+ 0x00c  ActiveCount      :  1
   
+ 0x00e  Flag             :  0x84
   
+ 0x010  SharedWaiters    :  0x87db2088  
   
+ 0x014  ExclusiveWaiters :  0x87db20c0  
   
+ 0x018  OwnerEntry       : _OWNER_ENTRY
      
+ 0x000  OwnerThread      :  0x85f55688
      
+ 0x004  IoPriorityBoosted : 0y0
      
+ 0x004  OwnerReferenced  : 0y0
      
+ 0x004  OwnerCount       : 0y000000000000000000000000000001 ( 0x1 )
      
+ 0x004  TableSize        :  4
   
+ 0x020  ActiveEntries    :  1
   
+ 0x024  ContentionCount  :  0x30
   
+ 0x028  NumberOfSharedWaiters :  0
   
+ 0x02c  NumberOfExclusiveWaiters :  3
   
+ 0x030  Address          : ( null
   
+ 0x030  CreatorBackTraceIndex :  0
   
+ 0x034  SpinLock         :  0

0 : kd >  dt nt ! _ERESOURCE  - 0x87b2 86 dc
   
+ 0x000  SystemResourcesList : _LIST_ENTRY [  0x87b286a4   -   0x87b11234  ]
      
+ 0x000  Flink            :  0x87b286a4  
      
+ 0x004  Blink            :  0x87b11234  
   
+ 0x008  OwnerTable       :  0x892d0130  
   
+ 0x00c  ActiveCount      :  1
   
+ 0x00e  Flag             :  0
   
+ 0x010  SharedWaiters    : ( null
   
+ 0x014  ExclusiveWaiters : ( null
   
+ 0x018  OwnerEntry       : _OWNER_ENTRY
      
+ 0x000  OwnerThread      : 0x8948 4 568
      
+ 0x004  IoPriorityBoosted : 0y0
      
+ 0x004  OwnerReferenced  : 0y0
      
+ 0x004  OwnerCount       : 0y000000000000000000000000000010 ( 0x2 )
      
+ 0x004  TableSize        :  8
   
+ 0x020  ActiveEntries    :  0xc
   
+ 0x024  ContentionCount  :  0
   
+ 0x028  NumberOfSharedWaiters :  0
   
+ 0x02c  NumberOfExclusiveWaiters :  0
   
+ 0x030  Address          : ( null
   
+ 0x030  CreatorBackTraceIndex :  0
   
+ 0x034  SpinLock         :  0

能看到ERESOURCE结构的 OwnerThread域正是上述分析的持有锁的线程。ERESOURCE结构定义大致如下:
typedef  struct  _ERESOURCE {
     LIST_ENTRY SystemResourcesList;
     POWNER_ENTRY OwnerTable;
     SHORT ActiveCount;
     USHORT Flag;
     PKSEMAPHORE SharedWaiters;
     PKEVENT ExclusiveWaiters;
     OWNER_ENTRY OwnerThreads[
2 ];
     ULONG ContentionCount;
     USHORT NumberOfSharedWaiters;
     USHORT NumberOfExclusiveWaiters;
     union{
         PVOID Address;
         ULONG_PTR CreatorBackTraceIndex;
     };
     KSPIN_LOCK SpinLock;
} ERESOURCE, 
* PERESOURCE;

现在比较可疑的是线程 0x85f55688 所持有的资源锁,列出这个线程的stack trace看看有没有hot spot:
0 : kd >   ! thread  0x85f55 688
THREAD 85f55688  Cid  0004.0024   Teb:  00000000  Win32Thread:  00000000  WAIT: (WrLpcReply) KernelMode Non - Alertable
    85f558bc  Semaphore Limit  0x1
Waiting  for  reply to ALPC Message 8e4a46b0 : queued at port 88c5cc18 : owned by process 88c09400
Not impersonating
DeviceMap                 8cc08a00
Owning Process             0        Image:          < Unknown >
Attached Process          85f22920       Image:         System
Wait Start TickCount       6525            Ticks:  30548  ( 0 : 00 : 07 : 56.551 )
Context Switch Count       9141              
UserTime                   00 : 00 : 00.000
KernelTime                 00 : 00 : 00.546
Win32 Start Address nt ! ExpWorkerThread ( 0x836abb1a )
Stack Init 8e907fd0 Current 8e907220 Base 8e908000 Limit 8e905000 Call  0
Priority  13  BasePriority  13  PriorityDecrement  0  IoPriority  2  PagePriority  5
ChildEBP RetAddr  Args to Child              
8e907238 836aca58 85f55688  00000000  83767d20 nt ! KiSwapContext + 0x26  (FPO: [Uses EBP] [ 0 , 0 , 4 ])
8e907270 836ab113 85f55748 85f55688 85f558bc nt ! KiSwapThread + 0x266
8e907298 836a524f 85f55688 85f55748  00000000  nt ! KiCommitThreadWait + 0x1df
8e907310 836f4ad7 85f558bc  00000011   00000000  nt ! KeWaitForSingleObject + 0x393
8e907338 838b3bae 85f558bc  00000000   00000000  nt ! AlpcpSignalAndWait + 0x7b
8e90735c 838a9c2f  00000000  8e9073c8  00000000  nt ! AlpcpReceiveSynchronousReply + 0x27
8e9073ec 8389d28f 88c5a6b0  00020000  8e907628 nt ! AlpcpProcessSynchronousRequest + 0x276
8e907448 838b4ad7 88c5a6b0 8e907628  00000000  nt ! LpcpRequestWaitReplyPort + 0x6a
8e907470 8368157a 80000c54 8e907628 8e907528 nt ! NtRequestWaitReplyPort + 0x4c
8e907470 8368024d 80000c54 8e907628 8e907528 nt ! KiFastCallEntry + 0x12a  (FPO: [ 0 , 3 ] TrapFrame @ 8e907484)
8e9074f4 98b63434 80000c54 8e907628 8e907528 nt ! ZwRequestWaitReplyPort + 0x11  (FPO: [ 3 , 0 , 0 ])
WARNING: Stack unwind information not available. Following frames may be wrong.
8e90772c 98b638a1  00000000   00000000  98b7d6ec tmcomm ! CWorkerThreadPool::CWorkerThreadPool + 0xa54
8e907744 98b9d97e 8e90775c  00000000  98ba6238 tmcomm ! KmCallUm + 0x75
8e907784 98b9ee09 9530af7c 162a554d 98ba6238 tmactmon + 0x397e
8e9077c0 98b9ef4d 0000000a  80000002  99ccc490 tmactmon + 0x4e09
8e9077ec 98b9efbc 8e907844  00000000  0000000a tmactmon + 0x4f4d
8e907800 98b8c450 8e907844  00000000  8e907950 tmactmon + 0x4fbc
8e907828 98b91f97 8e907802 8e9078a4 8e907950 tmevtmgr + 0x1450
8e90789c 98b921d7  00000000  88be10a4 8e907950 tmevtmgr ! TMEvtCommunicateRoutine + 0x2569
8e9078b4 98b8c450 8e907900 88be0edc 8e9079c8 tmevtmgr ! TMEvtCommunicateRoutine + 0x27a9
8e9078dc 98b90d0d 8e907903 8e9079a0 8e907a0c tmevtmgr + 0x1450
8e9079ac 98b8e7b0 8e9079c8 8e9079e4 98b8e944 tmevtmgr ! TMEvtCommunicateRoutine + 0x12df
8e9079b8 98b8e944 88be0f5c 8e9079c8 8e907acc tmevtmgr + 0x37b0
8e9079e4 8368157a 88be0f5c 8e907acc  82000000  tmevtmgr + 0x3944
8e9079e4 8367f069 88be0f5c 8e907acc  82000000  nt ! KiFastCallEntry + 0x12a  (FPO: [ 0 , 3 ] TrapFrame @ 8e907a0c)
8e907a7c 838266b5 8e907acc  82000000  8e907ad8 nt ! ZwCreateKey + 0x11  (FPO: [ 7 , 0 , 0 ])
8e907af0 8380e477 8e907cb8  82000000   00000000  nt ! IopCreateRegistryKeyEx + 0x61
8e907c18 8380e0bd 85f4d530  00000002   82000000  nt ! IopOpenOrCreateDeviceRegistryKey + 0x3b1
8e907c30 8c07e594 85f4d530  00000002   82000000  nt ! IoOpenDeviceRegistryKey + 0x18
8e907cc8 8c016489 87dbb0e0  00000000   00000000  ndis ! ndisCheckAdapterBindings + 0xa7  (FPO: [Non - Fpo])
8e907cf0 8c07d013 87dbbc70 87dbb0e0 8e907d50 ndis ! ndisQueuedRestoreMiniportstack + 0x36  (FPO: [Non - Fpo])
8e907d00 836abc27 87dbbc70  00000000  85f55688 ndis ! ndisWorkItemHandler + 0xe  (FPO: [Non - Fpo])
8e907d50 8384c643  00000000  a63db72a  00000000  nt ! ExpWorkerThread + 0x10d
8e907d90 836fe059 836abb1a  00000000   00000000  nt ! PspSystemThreadStartup + 0x9e
00000000   00000000   00000000   00000000   00000000  nt ! KiThreadStartup + 0x19

上述stack trace没有看出什么可疑的状态。再看看另外一个线程 0x8948 4 568(持有共享锁):
0 : kd >   ! thread  0x894845 68
THREAD  89484568   Cid 0cd0.0f50  Teb: 7ffa6000 Win32Thread: ffb39180 WAIT: (Executive) KernelMode Non - Alertable
    b44c6680  NotificationEvent
IRP List:
    
89493980 : ( 0006 , 0244 ) Flags:  00000884   Mdl:  00000000
    894d6db8: ( 0006 , 0244 ) Flags:  00000884   Mdl:  00000000
    88c4e9a0: ( 0006 , 0244 ) Flags:  00000884   Mdl:  00000000
    894d39a0: ( 0006 , 0244 ) Flags:  00000884   Mdl:  00000000
Not impersonating
DeviceMap                 8e12ea70
Owning Process             89020508        Image:          IMJPCMNT.E XE
Wait Start TickCount       4518            Ticks:  32555  ( 0 : 00 : 08 : 27.861 )
Context Switch Count       330              
UserTime                   00 : 00 : 00.000
KernelTime                 00 : 00 : 00.031
Win32 Start Address  0x697ee751
Stack Init b44c7fd0 Current b44c6550 Base b44c8000 Limit b44c5000 Call 6a0
Priority  10  BasePriority  8  PriorityDecrement  16  IoPriority  2  PagePriority  5
***  ERROR: Module load completed but symbols could not be loaded  for  flyfs.sys
ChildEBP RetAddr  Args to Child              
b44c6568 836aca58  89484568   00000000  807c2120 nt ! KiSwapContext + 0x26  (FPO: [Uses EBP] [ 0 , 0 , 4 ])
b44c65a0 836ab113  89484628   89484568  b44c6680 nt ! KiSwapThread + 0x266
b44c65c8 836a524f  89484568   89484628   00000000  nt ! KiCommitThreadWait + 0x1df
b44c6640 8bd6054f b44c6680  00000000   00000000  nt ! KeWaitForSingleObject + 0x393
b44c66a8 8bd5c54a 8bd5c4aa 894d5c90  00000003  fltmgr ! FltpPostSyncOperation + 0x8d  (FPO: [Non - Fpo])
b44c66cc 8bd59765 894d5c90  89435060  894d5c90 fltmgr ! FltpGetNormalizedFileName + 0x5e  (FPO: [Non - Fpo])
b44c66e4 8bd43773 894d5c90  00000000  894d5c90 fltmgr ! FltpCreateFileNameInformation + 0x81  (FPO: [Non - Fpo])
b44c6704 8bd438c7 877273c0  00000000   00000000  fltmgr ! HandleStreamListNotSupported + 0x125  (FPO: [Non - Fpo])
b44c6734 8bd43fa3 c00000bb  89435068  87b287d8 fltmgr ! FltpGetFileNameInformation + 0xc7  (FPO: [Non - Fpo])
b44c675c 8bd97a1d  00435068   00000101  b3187e2c fltmgr ! FltGetFileNameInformation + 0x12b  (FPO: [Non - Fpo])
b44c67d4 8bd892be  89435068   00000101  b3187e2c syscow32v ! SysCowGetFileNameInformation + 0xcd  (FPO: [Non - Fpo]) (CONV: stdcall) [d:\code\engineering\products\systemok\restore\driver\support.cpp @  2397 ]
b44c6868 8bd3daeb  89435068  b44c6888 b44c68b4 syscow32v ! SysCowPreCreate + 0x31e  (FPO: [Non - Fpo]) (CONV: stdcall) [d:\code\engineering\products\systemok\restore\driver\create.cpp @  299 ]
b44c68d4 8bd409f0 b44c6918  89493980   00000000  fltmgr ! FltpPerformPreCallbacks + 0x34d  (FPO: [Non - Fpo])
b44c68ec 8bd541fe b44c6918 8bd57f3c  00000000  fltmgr ! FltpPassThroughInternal + 0x40  (FPO: [Non - Fpo])
b44c6900 8bd548b7 b44c6918  89493980  89493b98 fltmgr ! FltpCreateInternal + 0x24  (FPO: [Non - Fpo])
b44c6944 8367a567 87e5d668  87727008  89493bbc fltmgr ! FltpCreate + 0x2c9  (FPO: [Non - Fpo])
b44c695c 8bda7bd1 89493ba0  89493980  892be848 nt ! IofCallDriver + 0x63
WARNING: Stack unwind information not available. Following frames may be wrong.
b44c6980 8bda91ec 87e5d7b0  89493980  b44c6a30 flyfs + 0x1bd1
b44c699c 8bda94f3 87e5d7b0 0000001b 894dab28 flyfs + 0x31ec
b44c6a50 8bda9f60 87e5d7b0  89493980  b44c6a70 flyfs + 0x34f3
b44c6a60 8bda9f8a 87e5d7b0  89493980  b44c6a88 flyfs + 0x3f60
b44c6a70 8367a567 87e5d7b0  89493980  894dab84 flyfs + 0x3f8a
b44c6a88 8387e5f5 9ce1a1da b44c6c30  00000000  nt ! IofCallDriver + 0x63
b44c6b60 8385f1a7 876f0678 87f6dde8 89403d20 nt ! IopParseDevice + 0xed7
b44c6bdc  83885215   00000000  b44c6c30  00000240  nt ! ObpLookupObjectName + 0x4fa
b44c6c3c 8387d573 b44c6dc0 85f6dde8  89484500  nt ! ObOpenObjectByName + 0x159
b44c6cb8 838b4d59 b44c6e04  00120089  b44c6dc0 nt ! IopCreateFile + 0x673
b44c6d14 83806c27 b44c6e04  00120089  b44c6dc0 nt ! IoCreateFileEx + 0x9e
b44c6d70 8bdac7c7 b44c6e04  00120089  b44c6dc0 nt ! IoCreateFileSpecifyDeviceObjectHint + 0x59
b44c6e10 8bda9593 0000004d b44c6ec0 87e5d7b0 flyfs + 0x67c7
b44c6ec8 8bda9f60 87e5d7b0 894d6db8 b44c6ee8 flyfs + 0x3593
b44c6ed8 8bda9f8a 87e5d7b0 894d6db8 b44c6f00 flyfs + 0x3f60
b44c6ee8 8367a567 87e5d7b0 894d6db8 892e76ac flyfs + 0x3f8a
b44c6f00 8387e5f5 9ce1a562 b44c70a8  00000000  nt ! IofCallDriver + 0x63
b44c6fd8 8385f1a7 876f0678 85f6dde8 894d8698 nt ! IopParseDevice + 0xed7
b44c7054  83885215   00000000  b44c70a8  00000240  nt ! ObpLookupObjectName + 0x4fa
b44c70b0 8387d573 b44c71d8 85f6dde8  00010000  nt ! ObOpenObjectByName + 0x159
b44c712c 838b4d59 894d5490  00100001  b44c71d8 nt ! IopCreateFile + 0x673
b44c7188 8bd5b8e5 894d5490  00100001  b44c71d8 nt ! IoCreateFileEx + 0x9e
b44c7220 8bd5bc59  00000000   00000000  0000fffe fltmgr ! FltpExpandFilePathWorker + 0x167  (FPO: [Non - Fpo])

IMJPCMNT.EXE是Microsoft输入法进程。


你可能感兴趣的:(Lock)