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

2009-03-08, 08:07 上午 rainynight 注册: 2009-03-08 发 贴: 8 这是什么问题导致的? BugCheck 1000008E, {c0000005, 8052bd97, ada3db7c, 0} Probably caused by : ntoskrnl.exe ( nt!CcGetLsnForFileObject+4f ) Followup: MachineOwner kd> !analyze -v Arguments: Arg1: c0000005, The exception code that was not handled Arg2: 8052bd97, The address that the exception occurred at Arg3: ada3db7c, Trap Frame Arg4: 00000000 Debugging Details: ------------------ EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx" FAULTING_IP: nt!CcGetLsnForFileObject+4f 8052bd97 f266af repne scas word ptr es:[edi] TRAP_FRAME: ada3db7c -- (.trap 0xffffffffada3db7c) ErrCode = 00000000 eax=00000000 ebx=076aff80 ecx=ffffffee edx=ada3dd18 esi=805d96b6 edi=076b0000 eip=8052bd97 esp=ada3dbf0 ebp=ada3dd30 iopl=0 nv up ei ng nz na pe cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010287 nt!CcGetLsnForFileObject+0x4f: 8052bd97 f266af repne scas word ptr es:[edi] es:0023:076b0000=???? Resetting default scope CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0x8E PROCESS_NAME: EXPLORER.EXE LAST_CONTROL_TRANSFER: from 8053e648 to 8052bd97 STACK_TEXT: ada3dd30 8053e648 00000a0c 00000000 00000000 nt!CcGetLsnForFileObject+0x4f ada3dd64 7c92e4f4 badb0d00 0352fc08 aedfad98 nt!PopRunDownSourceTargetList+0x10e WARNING: Frame IP not in any known module. Following frames may be wrong. ada3dd68 badb0d00 0352fc08 aedfad98 aedfadcc 0x7c92e4f4 ada3dd6c 0352fc08 aedfad98 aedfadcc 00000000 0xbadb0d00 ada3dd70 aedfad98 aedfadcc 00000000 00000000 0x352fc08 ada3dd74 aedfadcc 00000000 00000000 00000000 0xaedfad98 ada3dd78 00000000 00000000 00000000 00000000 0xaedfadcc STACK_COMMAND: kb FOLLOWUP_IP: nt!CcGetLsnForFileObject+4f 8052bd97 f266af repne scas word ptr es:[edi] SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: nt!CcGetLsnForFileObject+4f FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntoskrnl.exe DEBUG_FLR_IMAGE_TIMESTAMP: 48a3fbd8 FAILURE_BUCKET_ID: 0x8E_nt!CcGetLsnForFileObject+4f BUCKET_ID: 0x8E_nt!CcGetLsnForFileObject+4f Followup: MachineOwner --------- IP 地址: 已记录   报告

2009-03-11, 10:09 上午 王宇 注册: 2007-05-08 发 贴: 306 Re: 这是什么问题导致的? 首先，楼主是什么平台？ 我看了从 2000 到 Vista 平台，CcGetLsnForFileObject 函数的实现大致都是相同的。 都是获取 BCB 链的自旋锁，分析脏页，释放锁。 出错的指令是 F2 66 AF repne scas word ptr es:[edi]。这句是较为经典的字符串长度计算优化代码，一般用法如下： xor     eax, eax repne   scas byte ptr es:[edi] 作用就是在 es:[edi] 字符串里查找 AL (AL此时为0)，即寻找字符串的结束符，以计算长度。 这个功能和 CcGetLsnForFileObject 函数的实现基本无关 (或者就是我分析的目标和楼主不是一个平台，您Win7？) 我的第一个推断就是函数被 Patch 破坏了？？导致产生了错误的指令？ 所以请楼主 u 一下您平台的 CcGetLsnForFileObject 函数，以进一步分析、定位错误。谢谢。 IP 地址: 已记录   报告

2009-03-11, 17:10 下午 rainynight 注册: 2009-03-08 发 贴: 8 Re: 这是什么问题导致的? 我的平台是xp sp3 IP 地址: 已记录   报告

2009-03-11, 19:07 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 这是什么问题导致的? kd> u CcGetLsnForFileObject nt!CcGetLsnForFileObject: 8086d7ac 8bff            mov     edi,edi 8086d7ae 55              push    ebp 8086d7af 8bec            mov     ebp,esp 8086d7b1 83ec1c          sub     esp,1Ch 8086d7b4 8b4508          mov     eax,dword ptr [ebp+8]         ; 取 FileObject 8086d7b7 8b4014          mov     eax,dword ptr [eax+14h]       ; 取 FileObject->SectionObjectPointer 8086d7ba 33d2            xor     edx,edx 8086d7bc 56              push    esi 8086d7bd 8b7004          mov     esi,dword ptr [eax+4]         ; 取 FileObject->SectionObjectPointer->SharedCacheMap 到 esi 8086d7c0 33c0            xor     eax,eax 8086d7c2 3bf2            cmp     esi,edx                       ; if(SharedCacheMap == NULL) 8086d7c4 8945f8          mov     dword ptr [ebp-8],eax         ; Oldest.LowPart  = 0; (initialize lsn variables) 8086d7c7 8955fc          mov     dword ptr [ebp-4],edx         ; Oldest.HighPart = 0; (initialize lsn variables) 8086d7ca 8955f0          mov     dword ptr [ebp-10h],edx       ; Newest.LowPart  = 0; (initialize lsn variables) 8086d7cd 8955f4          mov     dword ptr [ebp-0Ch],edx       ; Newest.HighPart = 0; (initialize lsn variables) 8086d7d0 0f84a6000000    je      nt!CcGetLsnForFileObject+0xd0 (8086d87c) 8086d7d6 57              push    edi 8086d7d7 8d8eb8000000    lea     ecx,[esi+0B8h] 8086d7dd 8d55e4          lea     edx,[ebp-1Ch] 8086d7e0 ff15d4108080    call    dword ptr [nt!_imp_KeAcquireInStackQueuedSpinLock (808010d4)] ; ; FASTCALL : ; ; KeAcquireInStackQueuedSpinLock(&SharedCacheMap->BcbSpinLock, &LockHandle); ;                                |                             | ;                                |                             +-- [ebp-1Ch] ;                                +-- [esi+0B8h] (这指针类型是 _SHARED_CACHE_MAP) ; 8086d7e6 8d7e10          lea     edi,[esi+10h]       ; _SHARED_CACHE_MAP.BcbList (+0x010) 8086d7e9 8b07            mov     eax,dword ptr [edi] ; BcbList.Flink 8086d7eb 83e810          sub     eax,10h             ; 取到 _BCB 的首指针 8086d7ee 8d4810          lea     ecx,[eax+10h]       ; while (&Bcb->BcbLinks != &SharedCacheMap->BcbList) 8086d7f1 3bcf            cmp     ecx,edi             ; 8086d7f3 7465            je      nt!CcGetLsnForFileObject+0xae (8086d85a) 8086d7f5 53              push    ebx 8086d7f6 668138fd02      cmp     word ptr [eax],2FDh 8086d7fb 7550            jne     nt!CcGetLsnForFileObject+0xa1 (8086d84d) ; ; 显然 repne scas word ptr es:[edi] 是错误的指令，这句代码(F2 66 AF)根本不符合上下文语境。 ; 8086d7fd 80780200        cmp     byte ptr [eax+2],0 8086d801 744a            je      nt!CcGetLsnForFileObject+0xa1 (8086d84d) 8086d803 8b7020          mov     esi,dword ptr [eax+20h] ........ CcGetLsnForFileObject 函数内部相关数据结构： kd> dt nt!_FILE_OBJECT    +0x000 Type             : Int2B    +0x002 Size             : Int2B    +0x004 DeviceObject     : Ptr32 _DEVICE_OBJECT    +0x008 Vpb              : Ptr32 _VPB    +0x00c FsContext        : Ptr32 Void    +0x010 FsContext2       : Ptr32 Void >>>+0x014 SectionObjectPointer : Ptr32 _SECTION_OBJECT_POINTERS    +0x018 PrivateCacheMap  : Ptr32 Void    +0x01c FinalStatus      : Int4B    +0x020 RelatedFileObject : Ptr32 _FILE_OBJECT    +0x024 LockOperation    : UChar    +0x025 DeletePending    : UChar    +0x026 ReadAccess       : UChar    +0x027 WriteAccess      : UChar    +0x028 DeleteAccess     : UChar    +0x029 SharedRead       : UChar    +0x02a SharedWrite      : UChar    +0x02b SharedDelete     : UChar    +0x02c Flags            : Uint4B    +0x030 FileName         : _UNICODE_STRING    +0x038 CurrentByteOffset : _LARGE_INTEGER    +0x040 Waiters          : Uint4B    +0x044 Busy             : Uint4B    +0x048 LastLock         : Ptr32 Void    +0x04c Lock             : _KEVENT    +0x05c Event            : _KEVENT    +0x06c CompletionContext : Ptr32 _IO_COMPLETION_CONTEXT kd> dt nt!_SECTION_OBJECT_POINTERS    +0x000 DataSectionObject : Ptr32 Void >>>+0x004 SharedCacheMap   : Ptr32 Void    +0x008 ImageSectionObject : Ptr32 Void kd> dt nt!_SHARED_CACHE_MAP    +0x000 NodeTypeCode     : Int2B    +0x002 NodeByteSize     : Int2B    +0x004 OpenCount        : Uint4B    +0x008 FileSize         : _LARGE_INTEGER >>>+0x010 BcbList          : _LIST_ENTRY    +0x018 SectionSize      : _LARGE_INTEGER    +0x020 ValidDataLength  : _LARGE_INTEGER    +0x028 ValidDataGoal    : _LARGE_INTEGER    +0x030 InitialVacbs     : [4] Ptr32 _VACB    +0x040 Vacbs            : Ptr32 Ptr32 _VACB    +0x044 FileObject       : Ptr32 _FILE_OBJECT    +0x048 ActiveVacb       : Ptr32 _VACB    +0x04c NeedToZero       : Ptr32 Void    +0x050 ActivePage       : Uint4B    +0x054 NeedToZeroPage   : Uint4B    +0x058 ActiveVacbSpinLock : Uint4B    +0x05c VacbActiveCount  : Uint4B    +0x060 DirtyPages       : Uint4B    +0x064 SharedCacheMapLinks : _LIST_ENTRY    +0x06c Flags            : Uint4B    +0x070 Status           : Int4B    +0x074 Mbcb             : Ptr32 _MBCB    +0x078 Section          : Ptr32 Void    +0x07c CreateEvent      : Ptr32 _KEVENT    +0x080 WaitOnActiveCount : Ptr32 _KEVENT    +0x084 PagesToWrite     : Uint4B    +0x088 BeyondLastFlush  : Int8B    +0x090 Callbacks        : Ptr32 _CACHE_MANAGER_CALLBACKS    +0x094 LazyWriteContext : Ptr32 Void    +0x098 PrivateList      : _LIST_ENTRY    +0x0a0 LogHandle        : Ptr32 Void    +0x0a4 FlushToLsnRoutine : Ptr32     void    +0x0a8 DirtyPageThreshold : Uint4B    +0x0ac LazyWritePassCount : Uint4B    +0x0b0 UninitializeEvent : Ptr32 _CACHE_UNINITIALIZE_EVENT    +0x0b4 NeedToZeroVacb   : Ptr32 _VACB    +0x0b8 BcbSpinLock      : Uint4B    +0x0bc Reserved         : Ptr32 Void    +0x0c0 Event            : _KEVENT    +0x0d0 VacbPushLock     : _EX_PUSH_LOCK    +0x0d8 PrivateCacheMap  : _PRIVATE_CACHE_MAP    +0x130 WriteBehindWorkQueueEntry : Ptr32 Void // //  This is the Buffer Control Block structure for representing data which //  is "pinned" in memory by one or more active requests and/or dirty.  This //  structure is created the first time that a call to CcPinFileData specifies //  a particular integral range of pages.  It is deallocated whenever the Pin //  Count reaches 0 and the Bcb is not Dirty. // //  NOTE: The first four fields must be the same as the PUBLIC_BCB. // typedef struct _BCB {     union {         //         // To ensure QuadAlign (sizeof (BCB)) >= QuadAlign (sizeof (MBCB))         // so that they can share the same pool blocks.         //         MBCB Dummy;         struct {             //             //  Type and size of this record             //             CSHORT NodeTypeCode;             //             //  Flags             //             BOOLEAN Dirty;             BOOLEAN Reserved;             //             //  Byte FileOffset and and length of entire buffer             //             ULONG  ByteLength;             LARGE_INTEGER FileOffset;             //             //  Links for BcbList in SharedCacheMap             //             LIST_ENTRY BcbLinks;             //             //  Byte FileOffset of last byte in buffer (used for searching)             //             LARGE_INTEGER BeyondLastByte;             //             //  Oldest Lsn (if specified) when this buffer was set dirty.             //             LARGE_INTEGER OldestLsn;             //             //  Most recent Lsn specified when this buffer was set dirty.             //  The FlushToLsnRoutine is called with this Lsn.             //             LARGE_INTEGER NewestLsn;             //             //  Pointer to Vacb via which this Bcb is mapped.             //             PVACB Vacb;             //             //  Count of threads actively using this Bcb to process a request.             //  This must be manipulated under protection of the BcbListSpinLock             //  in the SharedCacheMap.             //             ULONG PinCount;             //             //  Resource to synchronize buffer access.  Pinning Readers and all Writers             //  of the described buffer take out shared access (synchronization of             //  buffer modifications is strictly up to the caller).  Note that pinning             //  readers do not declare if they are going to modify the buffer or not.             //  Anyone writing to disk takes out exclusive access, to prevent the buffer             //  from changing while it is being written out.             //             ERESOURCE Resource;             //             //  Pointer to SharedCacheMap for this Bcb.             //             PSHARED_CACHE_MAP SharedCacheMap;             //             //  This is the Base Address at which the buffer can be seen in             //  system space.  All access to buffer data should go through this             //  address.             //             PVOID BaseAddress;         };     }; } BCB; 还是那句话，楼主 U 一下你的 CcGetLsnForFileObject 函数以便分析。 IP 地址: 已记录   报告

2009-03-11, 22:16 下午 rainynight 注册: 2009-03-08 发 贴: 8 Re: 这是什么问题导致的? kd> u CcGetLsnForFileObject nt!CcGetLsnForFileObject: 8052bd48 0c8b or al,8Bh 8052bd4a 54 push esp 8052bd4b 2408 and al,8 8052bd4d c70200000000 mov dword ptr [edx],0 8052bd53 897a04 mov dword ptr [edx+4],edi 8052bd56 0bff or edi,edi 8052bd58 741e je nt!CcGetLsnForFileObject+0x30 (8052bd78) 8052bd5a 83c9ff or ecx,0FFFFFFFFh minidump:http://www.namipan.com/d/a43d91dae4533578bf97ac892eff1d70b0a133ea234f0000 IP 地址: 已记录   报告

2009-03-12, 10:31 上午 王宇 注册: 2007-05-08 发 贴: 306 Re: 这是什么问题导致的? 0. 楼主你早贴 minidump 就好了。当然，是 kernel dump 就更好了... 1. 楼主第一个帖子里的 dump 显然和实际的情况不符，Windbg 错误的栈定位到了： STACK_TEXT: ada3dd30 8053e648 00000a0c 00000000 00000000 nt!CcGetLsnForFileObject+0x4f ada3dd64 7c92e4f4 badb0d00 0352fc08 aedfad98 nt!PopRunDownSourceTargetList+0x10e WARNING: Frame IP not in any known module. Following frames may be wrong. 而 nt!CcGetLsnForFileObject 函数内部根本没有字符串 (repne scas word ptr es:[edi]) 相关操作，枉费我一番功夫呀。 进一步分析楼主贴出的 minidump 可以发现这次 Windbg 仍然有个小错误。 2. minidump 里的 nt!CcGetLsnForFileObject 如下： kd> u CcGetLsnForFileObject nt!CcGetLsnForFileObject: 804e5200 8bff            mov     edi,edi 804e5202 55              push    ebp 804e5203 8bec            mov     ebp,esp 804e5205 83ec1c          sub     esp,1Ch 804e5208 8b4508          mov     eax,dword ptr [ebp+8] 804e520b 8b4014          mov     eax,dword ptr [eax+14h] 804e520e 33d2            xor     edx,edx 804e5210 56              push    esi 804e5211 8b7004          mov     esi,dword ptr [eax+4] 804e5214 33c0            xor     eax,eax 804e5216 3bf2            cmp     esi,edx 804e5218 8945f8          mov     dword ptr [ebp-8],eax 804e521b 8955fc          mov     dword ptr [ebp-4],edx 804e521e 8955f0          mov     dword ptr [ebp-10h],edx 804e5221 8955f4          mov     dword ptr [ebp-0Ch],edx 804e5224 0f84a6000000    je      nt!CcGetLsnForFileObject+0xd0 (804e52d0) 804e522a 57              push    edi 804e522b 8d8eb8000000    lea     ecx,[esi+0B8h] 804e5231 8d55e4          lea     edx,[ebp-1Ch] 804e5234 ff1504874d80    call    dword ptr [nt!_imp_KeAcquireInStackQueuedSpinLock (804d8704)] 804e523a 8d7e10          lea     edi,[esi+10h] 804e523d 8b07            mov     eax,dword ptr [edi] 804e523f 83e810          sub     eax,10h 804e5242 8d4810          lea     ecx,[eax+10h] 804e5245 3bcf            cmp     ecx,edi 804e5247 7465            je      nt!CcGetLsnForFileObject+0xae (804e52ae) 804e5249 53              push    ebx 804e524a 668138fd02      cmp     word ptr [eax],2FDh 804e524f 7550            jne     nt!CcGetLsnForFileObject+0xa1 (804e52a1) 804e5251 80780200        cmp     byte ptr [eax+2],0 804e5255 744a            je      nt!CcGetLsnForFileObject+0xa1 (804e52a1) 804e5257 8b7020          mov     esi,dword ptr [eax+20h] 这个和我上面分析的帖子完全一致。而楼主您列出来的是？ -_-! 3. minidump 里显示，真正的问题比较复杂，我现在手头有点事，下个帖子给你分析一下。 IP 地址: 已记录   报告

2009-03-12, 11:15 上午 王宇 注册: 2007-05-08 发 贴: 306 Re: 这是什么问题导致的? 我能从 Minidump 中看出什么： 1. 楼主在玩魔兽 (或者你在写外挂搞魔兽) 2. Windbg 又出错了！ Windbg 告诉我们出错的 call stack 是： STACK_TEXT:  b694cbf4 b694cd18 1743cf2e b694cd64 0019e824 nt!RtlInitUnicodeString+0x1b WARNING: Frame IP not in any known module. Following frames may be wrong. b694cd30 8053e648 000026d8 00000000 00000000 0xb694cd18 b694cd30 7c92e4f4 000026d8 00000000 00000000 nt!KiFastCallEntry+0xf8 0019e86c 00000000 00000000 00000000 00000000 0x7c92e4f4 nt!KiFastCallEntry+0xd7: 8053e627 33c9            xor     ecx,ecx 8053e629 8a0c18          mov     cl,byte ptr [eax+ebx] 8053e62c 8b3f            mov     edi,dword ptr [edi] 8053e62e 8b1c87          mov     ebx,dword ptr [edi+eax*4] 8053e631 2be1            sub     esp,ecx 8053e633 c1e902          shr     ecx,2 8053e636 8bfc            mov     edi,esp 8053e638 3b35549a5580    cmp     esi,dword ptr [nt!MmUserProbeAddress (80559a54)] 8053e633 c1e902          shr     ecx,2 8053e636 8bfc            mov     edi,esp 8053e638 3b35549a5580    cmp     esi,dword ptr [nt!MmUserProbeAddress (80559a54)] 8053e63e 0f83a8010000    jae     nt!KiSystemCallExit2+0x9f (8053e7ec) 8053e644 f3a5            rep movs dword ptr es:[edi],dword ptr [esi] 8053e646 ffd3            call    ebx 8053e648 8be5            mov     esp,ebp 8053e64a 8b0d24f1dfff    mov     ecx,dword ptr ds:[0FFDFF124h] nt!KiFastCallEntry 告诉我们，一切正常，某些“好但是阴险”的钩子点没有工作，程序在 8053e646 准备进入 SSDT。但是 SSDT 里的某个项被 Hook 了。 WARNING: Frame IP not in any known module. Following frames may be wrong. b694cd30 8053e648 000026d8 00000000 00000000 0xb694cd18 << Hook! b694cd30 7c92e4f4 000026d8 00000000 00000000 nt!KiFastCallEntry+0xf8 那么，0xb694cd18 是什么？没有答案： kd> dd 0xb694cd18 b694cd18  00000000 1743cf2e 00320031 e2aee6e0 b694cd28  00040003 8588f008 b694cd64 8053e648 b694cd38  000026d8 00000000 00000000 1743ce10 b694cd48  00000000 1743bf98 00001000 00000003 b694cd58  8588f008 00000000 01000000 0019e86c b694cd68  7c92e4f4 badb0d00 0019e7f8 ffffffff b694cd78  b6ebfda0 00000000 00000000 00000000 b694cd88  00000000 00000000 00000000 00000000 结合栈桢分析，我发现这里是 Windbg 自己解析出错了！ 因为 nt!RtlInitUnicodeString 只开辟了一个局部变量，而这个分析显然有问题： kd> dd esp b694cbf0  b694cd64 f7bbd806 b694cd18 1743cf2e b694cc00  b694cd64 0019e824 f7bbd6ed 2e576f57 b694cc10  00657865 00000000 00000003 00000001 b694cc20  00004021 00000000 00000000 00000000 b694cc30  00000000 00000000 b694ccc4 f718a0c5 b694cc40  0019e5dc 00100001 0019e580 0019e5b0 b694cc50  00000003 00004021 855b1b00 ebfb2640 b694cc60  8060d590 ebf9f247 0019e5dc 00100001 kd> kb ChildEBP RetAddr  Args to Child              b694cbf4 b694cd18 1743cf2e b694cd64 0019e824 nt!RtlInitUnicodeString+0x1b WARNING: Frame IP not in any known module. Following frames may be wrong. b694cd30 8053e648 000026d8 00000000 00000000 0xb694cd18 b694cd30 7c92e4f4 000026d8 00000000 00000000 nt!KiFastCallEntry+0xf8 0019e86c 00000000 00000000 00000000 00000000 0x7c92e4f4 Windbg 认为： b694cd64 f7bbd806 是局部变量 b694cd18 是返回地址 1743cf2e 是参数一 b694cd64 是参数二 但是显然应该是： kd> dd esp b694cbf0  b694cd64 f7bbd806 b694cd18 1743cf2e b694cc00  b694cd64 0019e824 f7bbd6ed 2e576f57 b694cc10  00657865 00000000 00000003 00000001 b694cc20  00004021 00000000 00000000 00000000 b694cc30  00000000 00000000 b694ccc4 f718a0c5 b694cc40  0019e5dc 00100001 0019e580 0019e5b0 b694cc50  00000003 00004021 855b1b00 ebfb2640 b694cc60  8060d590 ebf9f247 0019e5dc 00100001 b694cd64 是局部变量 —— push    edi f7bbd806 是返回地址 —— 回到钩子函数里 b694cd18 是参数一   —— RtlInitUnicodeString 的 DestinationString 1743cf2e 是参数二   —— RtlInitUnicodeString 的 SourceString 这个猜想太大胆了 OK！验证一下： kd> u f7bbd806 *** WARNING: Unable to verify timestamp for hfile.sys *** ERROR: Module load completed but symbols could not be loaded for hfile.sys hfile+0x806: f7bbd806 ??              ???              ^ Memory access error in 'u f7bbd806' 原来是 hfile.sys 挂钩了 SSDT。google 一下，这可不是什么好东西！ kd> lm start    end        module name ........ f7bba000 f7bbad00   dxgthk     (deferred) f7bbd000 f7bbdf80   hfile    T (no symbols) f7c03000 f7c03b80   Null       (deferred) ........ --------------------------------------------------------------------------- RtlInitUnicodeString 参数一：b694cd18 kd> dt nt!_unicode_string b694cd18  "Logs???"    +0x000 Length           : 0    +0x002 MaximumLength    : 0    +0x004 Buffer           : 0x1743cf2e  "Logs???" --------------------------------------------------------------------------- RtlInitUnicodeString 参数二：1743cf2e kd> db 1743cf2e 1743cf2e  4c 00 6f 00 67 00 73 00-f8 e8 8a 6b 46 42 7e 72  L.o.g.s....kFB~r 1743cf3e  60 00 0c 7c e8 5a 09 03-22 28 0c 7c e5 39 58 78  `..|.Z.."(.|.9Xx 1743cf4e  78 78 8b 73 e5 41 8d 2d-3d 3d 2d 74 05 3a fd fd  xx.s.A.-==-t.:.. 1743cf5e  fd 01 8e 84 ec 6b 62 7a-7a f8 cb 6b 66 42 1c 18  .....kbzz..kfB.. 1743cf6e  d8 50 ab 6b 06 3a a0 78-9f 17 52 9d 87 42 e1 f2  .P.k.:.x..R..B.. 1743cf7e  f0 e0 eb 7c 26 3a 72 72-72 72 8b 6b 46 42 55 f5  ...|&:rrrr.kFBU. 1743cf8e  ad 0b eb 73 a8 4a f5 ff-2a 2a 0d 00 01 02 6f 10  ...s.J..**....o. 1743cf9e  70 05 e0 01 1c 00 80 85-28 00 f0 94 29 63 d5 9d  p.......(...)c.. 非常好！和我预期的一模一样~   B-) 我说到这里，楼主自己也能分析出蓝屏的原因了吧。 看样子 hfile.sys 驱动想初始化一个 UNICODE_STRING ——“LOGS”，但是它这里没有指定字符串的结束符： 1743cf2e  4c 00 6f 00 67 00 73 00-f8 e8 8a 6b 46 42 7e 72 1743cf2e  4c 00 6f 00 67 00 73 00-00 00 8a 6b 46 42 7e 72 << 这才是正确的！ 结果，可怜的 repne scas word ptr es:[edi] 指令，一直从地址 1743cf2e  计算字符串长度到 1743d000： eax=00000000 ebx=1743ced0 ecx=ffffff96 edx=b694cd18 esi=805d96b6 edi=1743d000 eip=8052bd97 esp=b694cbf0 ebp=b694cd30 iopl=0         nv up ei pl nz ac pe cy cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010217 看看这一段吧： kd> db 1743cf2e 1743d000 1743cf2e  4c 00 6f 00 67 00 73 00-f8 e8 8a 6b 46 42 7e 72  L.o.g.s....kFB~r 1743cf3e  60 00 0c 7c e8 5a 09 03-22 28 0c 7c e5 39 58 78  `..|.Z.."(.|.9Xx 1743cf4e  78 78 8b 73 e5 41 8d 2d-3d 3d 2d 74 05 3a fd fd  xx.s.A.-==-t.:.. 1743cf5e  fd 01 8e 84 ec 6b 62 7a-7a f8 cb 6b 66 42 1c 18  .....kbzz..kfB.. 1743cf6e  d8 50 ab 6b 06 3a a0 78-9f 17 52 9d 87 42 e1 f2  .P.k.:.x..R..B.. 1743cf7e  f0 e0 eb 7c 26 3a 72 72-72 72 8b 6b 46 42 55 f5  ...|&:rrrr.kFBU. 1743cf8e  ad 0b eb 73 a8 4a f5 ff-2a 2a 0d 00 01 02 6f 10  ...s.J..**....o. 1743cf9e  70 05 e0 01 1c 00 80 85-28 00 f0 94 29 63 d5 9d  p.......(...)c.. 1743cfae  9d 15 19 d7 92 ad f2 fa-72 5a 13 be 71 ad 3f 7b  ........rZ..q.?{ 1743cfbe  eb 82 f2 b5 2f a5 00 fd-af ae ae 94 46 42 d6 d4  ..../.......FB.. 1743cfce  d4 d4 cf a4 c8 5a 45 85-27 07 ad 8c c9 52 25 2d  .....ZE.'....R%- 1743cfde  2d 29 2f 9d 0b 74 7f 7f-6e ca e8 5a 66 4a a4 b6  -)/..t..n..ZfJ.. 1743cfee  b6 b4 b2 a5 08 5b 15 d5-d5 95 b2 ad ef 9c f8 f8  .....[.......... 1743cffe  f1 e8 ??                                         ..? 为了找 00 00 结束符，指令一直访问到地址错误、蓝屏，精神可嘉。 最后对楼主的建议： 1. 玩 WOW 前赶紧卸载那什么 hfile.sys 小心它 LOGS 你的密码啥的。 2. 开启360。我发现你的机器上有360，但是自我保护没开启。 /* *** WARNING: Unable to verify timestamp for safeboxkrnl.sys *** ERROR: Module load completed but symbols could not be loaded for safeboxkrnl.sys */ 3. 您若是无聊就把 hfile.sys 发给我看看 (wangyu_at_qihoo_dot_net)，我若是无聊就把它给逆了。 4. 写的累死我了，楼主给点掌声吧...   : P   IP 地址: 已记录   报告

2009-03-12, 12:17 下午 nightxie 注册: 2008-06-09 发 贴: 43 Re: 这是什么问题导致的? 给点掌声你~~~分析的很好。。。膜拜~~~ IP 地址: 已记录   报告

2009-03-12, 16:16 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 这是什么问题导致的? 刚封装完一个库，小感慨一下， CSRSS 启动的命令行参数够变态... 1: kd> ?? pUnit struct _PROCESS_UNIT * 0x817da150    +0x000 Next             : (null)    +0x004 Index            : 4    +0x008 Hidden           : 0    +0x00c Keyword          : 0    +0x010 UniqueProcessId  : 0x0000029c    +0x014 ParentProcessId  : 0x0000026c    +0x018 pUniqueEProcess  : 0x81688020 _EPROCESS    +0x01c pParentEProcess  : 0x8184f118 _EPROCESS    +0x020 ProcessFileName  : _STRING "csrss.exe"    +0x028 ProcessPathName  : _STRING "C:\WINDOWS\system32\csrss.exe"    +0x030 CommandLine      : _STRING "C:\WINDOWS\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16" IP 地址: 已记录   报告

2009-03-12, 20:51 下午 rainynight 注册: 2009-03-08 发 贴: 8 Re: 这是什么问题导致的? 非常棒,感谢王宇的分析,掌声 IP 地址: 已记录   报告

2009-03-12, 21:06 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 这是什么问题导致的? 嘿嘿 谢谢你们呀！ ^_^ : P IP 地址: 已记录   报告

2009-03-12, 22:12 下午 rainynight 注册: 2009-03-08 发 贴: 8 Re: 这是什么问题导致的? 请教个问题,我windbg打开那个minidump call stack 是： STACK_TEXT: b694cd30 8053e648 000026d8 00000000 00000000 nt!CcGetLsnForFileObject+0x4f b694cd64 7c92e4f4 badb0d00 0019e7f8 ffffffff nt!PopRunDownSourceTargetList+0x10e WARNING: Frame IP not in any known module. Following frames may be wrong. b694cd68 badb0d00 0019e7f8 ffffffff b6ebfda0 0x7c92e4f4 b694cd6c 0019e7f8 ffffffff b6ebfda0 00000000 0xbadb0d00 b694cd70 ffffffff b6ebfda0 00000000 00000000 0x19e7f8 b694cd74 b6ebfda0 00000000 00000000 00000000 0xffffffff b694cd78 00000000 00000000 00000000 00000000 0xb6ebfda0 IP 地址: 已记录   报告

2009-03-12, 23:11 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 这是什么问题导致的? 王宇分析的很生动!不过还有值得挖掘的地方，使用dds命令看一下栈，很可能还执行过其它模块的函数： kd> dds esp b694cbf0  b694cd64 b694cbf4  f7bbd806 hfile+0x806 b694cbf8  b694cd18 b694cbfc  1743cf2e b694cc00  b694cd64 b694cc04  0019e824 b694cc08  f7bbd6ed hfile+0x6ed b694cc0c  2e576f57 b694cc10  00657865 b694cc14  00000000 b694cc18  00000003 b694cc1c  00000001 b694cc20  00004021 b694cc24  00000000 b694cc28  00000000 b694cc2c  00000000 b694cc30  00000000 b694cc34  00000000 b694cc38  b694ccc4 b694cc3c  f718a0c5 kl1+0x20c5 b694cc40  0019e5dc b694cc44  00100001 b694cc48  0019e580 b694cc4c  0019e5b0 b694cc50  00000003 b694cc54  00004021 b694cc58  855b1b00 b694cc5c  ebfb2640 cmdguard+0x16640 b694cc60  8060d590 nt!ProbeForRead b694cc64  ebf9f247 cmdguard+0x3247 b694cc68  0019e5dc b694cc6c  00100001 楼主是否有可能产生一个kernel dump或者full dump（最好），然后压缩一下传上来？   IP 地址: 已记录   报告

2009-03-13, 18:30 下午 王宇 注册: 2007-05-08 发 贴: 306 Re: 这是什么问题导致的? 看了一下 hfile.sys 是一个写的很不好的文件夹过滤驱动(SSDT Hook NtQueryDirectoryFile)...... 甚至还不及 Rootkit.com 的 Demo IP 地址: 已记录   报告

2009-03-24, 17:04 下午 aa1ss2 注册: 2009-03-24 发 贴: 14 Re: 这是什么问题导致的? 太牛了，鼓掌~ 这个帖子学到了不少东西，另外请问一下，字体变色是怎么搞的啊？ IP 地址: 已记录   报告

总页数 1 第 2 页 [共有 16 条记录] 1 2 >

高端调试 » 软件调试 » WinDbg » 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 |- 游戏开发与调试