Advanced Debugging
About AdvDbg Consult Train Services Products Tools Community Contact  
欢迎光临 高端调试 登录 | 注册 | FAQ
 
  ACPI调试
Linux内核调试
Windows内核调试
 
  调试战役
调试原理
新工具观察
 
  Linux
Windows Vista
Windows
 
  Linux驱动
WDF
WDM
 
  PCI Express
PCI/PCI-X
USB
无线通信协议
 
  64位CPU
ARM
IA-32
  CPU Info Center
 
  ACPI标准
系统认证
Desktop
服务器
 
  Embedded Linux
嵌入式开发工具
VxWorks
WinCE
嵌入式Windows
 
  易内核
  小朱书店
  老雷的微博
  《软件调试》
  《格蠹汇编》
沪ICP备11027180号

Windows内核调试

帖子发起人: jlflyfox   发起时间: 2009-02-06 13:04 下午   回复: 25

Print Search
帖子排序:    
   2009-02-06, 13:04 下午
jlflyfox 离线,最后访问时间: 2009-1-24 22:08:06 jlflyfox

发帖数前25位
注册: 2008-10-28
发 贴: 65
oracle+macfee导致BSOD?
Reply Quote
另外有两次bsod,全部内存转储,都是由于oracle的一个进程出现问题,但是macfee杀毒软件的一个驱动mfehidk.sys造成的,而这两次能看到!apc,两次大致类似,我贴一份参考;
还有一次只有bsod只有核心内存转储,是rkhdrv40.sys的,应该是我当时运行RkUnhooker时bsod的
oracle+macfee造成bsod
--------------------------------------
----------------------------------------
Loading Dump File [F:\work\crash\nanjing\MEMORY02042247.DMP]
Kernel Complete Dump File: Full address space is available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 3790.srv03_sp1_rtm.050324-1447
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Debug session time: Thu Feb 5 08:39:57.031 2009 (GMT+8)
System Uptime: 0 days 9:53:48.734
Loading Kernel Symbols
.................................................................................................
Loading User Symbols
UserMode Module List Address is NULL (Addr= 7c9b9e0c)
This is usually caused by being in the wrong process
context or by paging
Loading unloaded module list
.....................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1A, {3452, 1001a101, c08840ec, 0}

Probably caused by : mfehidk.sys

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

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

MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 00003452, The subtype of the bugcheck.
Arg2: 1001a101
Arg3: c08840ec
Arg4: 00000000

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


BUGCHECK_STR: 0x1a_3452

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: emdctl.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 8084c103 to 80827451

STACK_TEXT:
b627eaa8 8084c103 0000001a 00003452 1001a101 nt!KeBugCheckEx+0x1b
b627ec64 8084c24d 89d7fd88 89d7fd88 00000000 nt!MiDeleteAddressesInWorkingSet+0x155
b627ec84 8094b539 89d7ffb0 8962bdb0 8962bff0 nt!MmCleanProcessAddressSpace+0x111
b627ed0c 8094b68d 00000003 00000000 89d7fd88 nt!PspExitThread+0x5f1
b627ed24 8094b887 8962bdb0 00000003 00000001 nt!PspTerminateThreadByPointer+0x4b
b627ed54 80888c6c 00000000 00000003 0012ff14 nt!NtTerminateProcess+0x125
b627ed54 7c95ed54 00000000 00000003 0012ff14 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012fe1c 7c952034 7c81300a ffffffff 00000003 0x7c95ed54
0012ff14 7c81304d 00000003 77e8f3b0 ffffffff 0x7c952034
0012ff28 7c348d04 00000003 7c3476c9 00000003 0x7c81304d
0012ff60 7c348d11 00000003 00000000 00000000 0x7c348d04
0012ffc0 7c8123cd 00000000 00000000 7ffdb000 0x7c348d11
0012fff0 00000000 00404068 00000000 00000000 0x7c8123cd


STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
8094b762-8094b766 5 bytes - nt!NtTerminateProcess
[ 8b ff 55 8b ec:e9 84 2d 1f 36 ]
5 errors : !nt (8094b762-8094b766)

MODULE_NAME: mfehidk

IMAGE_NAME: mfehidk.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4589691f

FOLLOWUP_NAME: MachineOwner

MEMORY_CORRUPTOR: PATCH_mfehidk

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_PATCH_mfehidk

BUCKET_ID: MEMORY_CORRUPTION_PATCH_mfehidk

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

0: kd> !apc
*** Enumerating APCs in all processes
Process 89d17818 System
Process 89b8c140 SMSS.EXE
Process 89b08020 csrss.exe
Process 89c34020 winlogon.exe
Process 89a59020 services.exe
Process 89b12020 savedump.exe
Process 89b92148 lsass.exe
Process 89bc4528 svchost.exe
Process 89b32488 svchost.exe
Process 89b45c08 svchost.exe
Process 89b81bc8 svchost.exe
Process 89b81750 svchost.exe
Process 89cc4a38 spoolsv.exe
Process 89aeeb18 msdtc.exe
Process 89a0ea38 svchost.exe
Process 89ba7860 FrameworkServic
Process 89b86d88 Mcshield.exe
Process 89a1a8a0 naPrdMgr.exe
Process 899d2790 VsTskMgr.exe
Process 89a12610 nmesrvc.exe
Process 89bbf9e8 isqlplussvc.exe
Process 89b337f8 cmd.exe
Process 897b6310 TNSLSNR.exe
Process 89a51848 java.exe
Process 89760900 ORACLE.EXE
Process 89bfca10 svchost.exe
Process 89d7d778 r_server.exe
Process 890fdad0 wmiprvse.exe
Process 89705020 cmd.exe
Process 895f8020 perl.exe
Process 89116ae0 java.exe
Process 896b2be0 cmd.exe
Process 899fb890 svchost.exe
Process 896a6020 svchost.exe
Process 8968eb88 emagent.exe
Process 8966c598 logon.scr
Process 88fa0d88 McScript_InUse.
Process 89bc3d88 csrss.exe
Process 896814c8 winlogon.exe
Process 89027ab0 rdpclip.exe
Process 89050020 Explorer.EXE
Process 89751b18 UdaterUI.exe
Process 8964b850 SHSTAT.EXE
Process 88fc6668 ctfmon.exe
Process 88f8a020 plsqldev.exe
Process 899df328 FlashFXP.exe
Process 89c92aa8 Mcshield.exe
Process 8962d800 cmd.exe
Process 89d7fd88 emdctl.exe


IP 地址: 已记录   报告
   2009-02-06, 13:07 下午
jlflyfox 离线,最后访问时间: 2009-1-24 22:08:06 jlflyfox

发帖数前25位
注册: 2008-10-28
发 贴: 65
rkunhooker导致BSOD
Reply Quote
rkunhooker导致BSOD
---------------------------------
----------------------------------
Loading Dump File [F:\work\crash\nanjing\MEMORY02051650.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 3790.srv03_sp1_rtm.050324-1447
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af988
Debug session time: Thu Feb 5 16:46:17.468 2009 (GMT+8)
System Uptime: 0 days 0:04:58.046
Loading Kernel Symbols
..................................................................................................
Loading User Symbols

Loading unloaded module list
..................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {edfe87b, 1b, 0, 8083a9dc}

*** ERROR: Module load completed but symbols could not be loaded for rkhdrv40.SYS
Probably caused by : rkhdrv40.SYS

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0edfe87b, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8083a9dc, address which referenced memory

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


READ_ADDRESS: 0edfe87b

CURRENT_IRQL: 1b

FAULTING_IP:
nt!SwapContext+10
8083a9dc 33837b08000f xor eax,dword ptr [ebx+0F00087Bh]

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: b7050c8c -- (.trap 0xffffffffb7050c8c)
ErrCode = 00000000
eax=89b2a5a8 ebx=ffdfe000 ecx=00000000 edx=89b2a5a8 esi=89b2a5a8 edi=89442020
eip=8083a9dc esp=b7050d00 ebp=b7050d44 iopl=0 nv up ei ng nz na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010283
nt!SwapContext+0x10:
8083a9dc 33837b08000f xor eax,dword ptr [ebx+0F00087Bh] ds:0023:0edfe87b=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 8083a9dc to 80837ed5

STACK_TEXT:
b7050c8c 8083a9dc badb0d00 89b2a5a8 89b7f960 nt!KiTrap0E+0x2a7
b7050d54 f7147488 b7050d84 ffe17b80 f71477e6 nt!SwapContext+0x10
WARNING: Stack unwind information not available. Following frames may be wrong.
b7050d60 f71477e6 b1c4dc8e 00000000 b7050da4 rkhdrv40+0x488
b7050d8c f714afac 00000000 00000000 ffdff600 rkhdrv40+0x7e6
b7050dac 8092ccff 00000000 00000000 00000000 rkhdrv40+0x3fac
b7050ddc 80841a96 f714af2f 00000000 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
8083a9cc-8083a9d3 8 bytes - nt!SwapContext
[ 51 80 7e 5d 00 74 04 f3:e9 72 d1 90 76 ff 33 83 ]
8083de4d-8083de51 5 bytes - nt!KeDelayExecutionThread (+0x3481)
[ 8b ff 55 8b ec:e9 88 99 90 76 ]
808940fd-808940ff 3 bytes - nt!ExAllocatePool (+0x562b0)
[ 8b ff 55:e9 79 36 ]
80894101 - nt!ExAllocatePool+4 (+0x04)
[ ec:76 ]
8089b72a-8089b72e 5 bytes - nt!ExAllocatePoolWithTag
[ 8b ff 55 8b ec:e9 7c c0 8a 76 ]
8091288d-80912891 5 bytes - nt!NtTerminateProcess
[ 8b ff 55 8b ec:e9 59 7c e7 36 ]
27 errors : !nt (8083a9cc-80912891)

MODULE_NAME: rkhdrv40

IMAGE_NAME: rkhdrv40.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 46acad0d

FOLLOWUP_NAME: MachineOwner

MEMORY_CORRUPTOR: PATCH_rkhdrv40

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_PATCH_rkhdrv40

BUCKET_ID: MEMORY_CORRUPTION_PATCH_rkhdrv40

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


IP 地址: 已记录   报告
   2009-02-06, 14:36 下午
WANGyu 离线,最后访问时间: 2012-9-10 3:34:00 王宇

发帖数前10位
男
注册: 2007-05-08
发 贴: 306
Re: rkunhooker导致BSOD
Reply Quote

唉... 一看就知道是 Rku Inline SwapContext 瞎搞...

2003 平台下 SwapContext 的反汇编如下(注意看红色指令):

0: kd> u SwapContext
nt!SwapContext:
8088d040 51              push    ecx
8088d041 807e5d00        cmp     byte ptr [esi+5Dh],0
8088d045 7404            je      nt!SwapContext+0xb (8088d04b)
8088d047 f390            pause
8088d049 ebf6            jmp     nt!SwapContext+0x1 (8088d041)
8088d04b 26ff4310        inc     dword ptr es:[ebx+10h]
8088d04f ff33            push    dword ptr [ebx]
8088d051 837b0800        cmp     dword ptr [ebx+8],0
8088d055 0f8529010000    jne     nt!ScPatchFxe+0x13 (8088d184)
8088d05b 0f20c5          mov     ebp,cr0
8088d05e 8bd5            mov     edx,ebp

那么,蓝屏语句

nt!SwapContext+10
8083a9dc 33837b08000f xor eax,dword ptr [ebx+0F00087Bh]

是什么?

显然是指令碎片......

系统执行这个指令焉有不蓝屏之理? 当时 EBX 的值是:ffdfe000 + 0F00087Bh = 10EDFE87B

结果 CPU 就很无辜地去访问 0edfe87b 了:

Arg1: 0edfe87b, memory referenced
Arg2: 0000001b, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 8083a9dc, address which referenced memory

所以,这个 BSOD 是 Rku 自己的 Hook 时不 pause 其它 CPU 造成的,和楼主的问题无关。楼主使的是什么版本的 Rku?


Ps : F:\work\crash\nanjing\MEMORY02051650.DMP

啊.. 南京.. 我的家乡......


IP 地址: 已记录   报告
   2009-02-06, 15:48 下午
jlflyfox 离线,最后访问时间: 2009-1-24 22:08:06 jlflyfox

发帖数前25位
注册: 2008-10-28
发 贴: 65
Re: WaitForSingleObject导致BSOD?
Reply Quote
分析得很好啊,我当时就没有懂!
版本是3.7.300.503

我明天尝试给你们一个ftp地址。
IP 地址: 已记录   报告
   2009-02-06, 17:02 下午
jlflyfox 离线,最后访问时间: 2009-1-24 22:08:06 jlflyfox

发帖数前25位
注册: 2008-10-28
发 贴: 65
Re: WaitForSingleObject导致BSOD?
Reply Quote
另外,再请问下如何在dump文件中找隐藏驱动,我怀疑有驱动隐藏了
我用lm看到的似乎都是不坏的driver
IP 地址: 已记录   报告
   2009-02-06, 18:59 下午
WANGyu 离线,最后访问时间: 2012-9-10 3:34:00 王宇

发帖数前10位
男
注册: 2007-05-08
发 贴: 306
Re: WaitForSingleObject导致BSOD?
Reply Quote
单从 dump 文件看隐藏的模块比较困难,除非是它的(Hook等)信息残留在栈上?

如果有调试器事情就简单了一些,或者像 MJ、Joanna 等人的代码那样暴力找 PE / pdb 串等等。
IP 地址: 已记录   报告
   2009-02-07, 19:15 下午
jlflyfox 离线,最后访问时间: 2009-1-24 22:08:06 jlflyfox

发帖数前25位
注册: 2008-10-28
发 贴: 65
Re: WaitForSingleObject导致BSOD?
Reply Quote
请两位收邮件,我已经发送了
可惜ftp不好弄
IP 地址: 已记录   报告
   2009-02-09, 13:07 下午
WANGyu 离线,最后访问时间: 2012-9-10 3:34:00 王宇

发帖数前10位
男
注册: 2007-05-08
发 贴: 306
Re: WaitForSingleObject导致BSOD?
Reply Quote

刚吃完饭,看了一下 DUMP:

首先,栈上的参数确实是不一样,但这不是问题的所在:

b8a60aa8 8084c103 0000001a 00003452 60839101 nt!KeBugCheckEx+0x1b
b8a60c64 8084c24d 88cc8d88 88cc8d88 00000000 nt!MiDeleteAddressesInWorkingSet+0x155
b8a60c84 8094b539 88cc8fb0 88cf12f8 88cf1538 nt!MmCleanProcessAddressSpace+0x111
b8a60d0c 8094b68d 00000003 00000000 88cc8d88 nt!PspExitThread+0x5f1
b8a60d24 8094b887 88cf12f8 00000003 00000001 nt!PspTerminateThreadByPointer+0x4b
b8a60d54 80888c6c 00000000 00000003 0012ff14 nt!NtTerminateProcess+0x125
b8a60d54 7c95ed54 00000000 00000003 0012ff14 nt!KiFastCallEntry+0xfc

我怀疑是编译器生成的代码,“优化”破坏了参数 PEPROCESS。


问题的实际原因是 PTE 的校验出错。MiDeleteAddressesInWorkingSet 部分源码如下:

VOID
MiDeleteAddressesInWorkingSet (
    IN PEPROCESS Process
    )

/*++

Routine Description:

    This routine deletes all user mode addresses from the working set list.

Arguments:

    Process - Supplies a pointer to the current process.

Return Value:

    None.

Environment:

    Kernel mode, Working Set Lock held.

--*/

{
    PVOID Va;
    PMMPTE PointerPte;
    ......

        ......

        Va = Wsle->u1.VirtualAddress;

        //
        // Ensure the WSLE and the PTE are both valid so that any
        // conflict between them can be resolved before both are deleted.
        //

        PointerPte = MiGetPteAddress (Va);

        if (PointerPte->u.Hard.Valid == 0) {
            KeBugCheckEx (MEMORY_MANAGEMENT,
                          0x3452,
                          (ULONG_PTR) Va,
                          (ULONG_PTR) Wsle,
                          (ULONG_PTR) PointerPte->u.Long);
        }

    ......
}

这对应楼主的蓝屏(nt!MiDeleteAddressesInWorkingSet+0x155):

0: kd>
nt!MiDeleteAddressesInWorkingSet+0x13f:
8084c0ed c9              leave
8084c0ee c20400          ret     4
8084c0f1 ff36            push    dword ptr [esi]
8084c0f3 ff75fc          push    dword ptr [ebp-4]
8084c0f6 51              push    ecx
8084c0f7 6852340000      push    3452h
8084c0fc 6a1a            push    1Ah
8084c0fe e833b3fdff      call    nt!KeBugCheckEx (80827436)
0: kd>
nt!MiDeleteAddressesInWorkingSet+0x155:
8084c103 cc              int     3
8084c104 41              inc     ecx
8084c105 20647269        and     byte ptr [edx+esi*2+69h],ah
8084c109 7665            jbe     nt!MmCleanProcessAddressSpace+0x34 (8084c170)
8084c10b 7220            jb      nt!MiDeleteAddressesInWorkingSet+0x17f (8084c12d)
8084c10d 686173206c      push    6C207361h
8084c112 6561            popad
8084c114 6b656420        imul    esp,dword ptr [ebp+64h],20h

上次看 Bug Check Code Reference 的时候,我很好奇 Bug Check 0x1A: MEMORY_MANAGEMENT 蓝屏的参数,微软告诉我们 —— Parameter 1 is the only parameter of interest; this identifies the exact violation. 那么,剩下的参数都是干什么的呢?

MEMORY_MANAGEMENT (1a)
    # Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 00003452, The subtype of the bugcheck.
Arg2: 60839101
Arg3: c0881fec
Arg4: 00000000

现在我知道了,原来参数4 是 (ULONG_PTR) PointerPte->u.Long。很好!

对照 \base\ntos\mm\i386\mi386.h 可以看出这个联合体和 if (PointerPte->u.Hard.Valid == 0) 的关系:

typedef struct _MMPTE {
    union  {
        ULONG Long;
        HARDWARE_PTE Flush;
        MMPTE_HARDWARE Hard;
        MMPTE_PROTOTYPE Proto;
        MMPTE_SOFTWARE Soft;
        MMPTE_TRANSITION Trans;
        MMPTE_SUBSECTION Subsect;
        MMPTE_LIST List;
        } u;
} MMPTE;

而这个32位的 PTE 的位是这样定义的:

//
// A Page Table Entry on the x86 has the following definition.
// Note the MP version is to avoid stalls when flushing TBs across processors.
//

typedef struct _MMPTE_HARDWARE {
    ULONG Valid : 1;
#if defined(NT_UP)
    ULONG Write : 1;       // UP version
#else
    ULONG Writable : 1;    // changed for MP version
#endif
    ULONG Owner : 1;
    ULONG WriteThrough : 1;
    ULONG CacheDisable : 1;
    ULONG Accessed : 1;
    ULONG Dirty : 1;
    ULONG LargePage : 1;
    ULONG Global : 1;
    ULONG CopyOnWrite : 1; // software field
    ULONG Prototype : 1;   // software field
#if defined(NT_UP)
    ULONG reserved : 1;    // software field
#else
    ULONG Write : 1;       // software field - MP change
#endif
    ULONG PageFrameNumber : 20;
} MMPTE_HARDWARE, *PMMPTE_HARDWARE;





现在很清楚了,内核在校验 if (PointerPte->u.Hard.Valid == 0) 时主动产生的蓝屏。此时的 PTE 是 00000000 (PointerPte->u.Long)。PointerPte->u.Hard.Valid 所指的是 PTE 的 Present 位(bit0, P flag),也就是说这是一个无效PTE。而正常情况下不是这样的。

OK。谁破坏了页面属性呢? 另 Oracle 数据库会影响页面大小等吗?(Arg1: 00003452, The subtype of the bugcheck. Arg2: 004b2221 Arg3: c0884bfc Arg4: 00000080 - Page size (PS) flag, bit 7,When the flag is set, the page size is 4 MBytes for normal 32-bit addressing (and 2 MBytes if extended physical addressing is enabled) and the pagedirectory entry points to a page.


IP 地址: 已记录   报告
   2009-02-09, 16:36 下午
jlflyfox 离线,最后访问时间: 2009-1-24 22:08:06 jlflyfox

发帖数前25位
注册: 2008-10-28
发 贴: 65
Re: WaitForSingleObject导致BSOD?
Reply Quote
谢谢!
是不是这个时候还没有换页过来?--当然这个可能性太小。
bsod发生不仅在oracle的相关进程,其他进程也很容易导致,共同点就是都需要大量内存。
所以我曾经有点怀疑是换页出的问题。
但我自己写了一个测试程序,要求分配500M物理内存,对其间地址内容都赋值,保证物理内存真正提交使用 (光VirtualAlloc+MEM_COMMIT还不行),连续运行4个实例,超过真正物理内存2G,结果没有发生什么事情。
它的文件系统都是FAT32,应该也没有什么问题吧,虽然不是很爽......
IP 地址: 已记录   报告
   2016-07-13, 23:40 下午
kinjo 离线,最后访问时间: 2016-7-13 15:38:59 kinjo

发帖数前500位
注册: 2016-07-13
发 贴: 2
Re: WaitForSingleObject导致BSOD?
Reply Quote
同样的BSOD和我一起过
IP 地址: 已记录   报告
   2016-07-15, 20:14 下午
kinjo 离线,最后访问时间: 2016-7-13 15:38:59 kinjo

发帖数前500位
注册: 2016-07-13
发 贴: 2
Re: WaitForSingleObject导致BSOD?
Reply Quote
We found a solution
IP 地址: 已记录   报告
  总页数 2 第 2 页 [共有 26 条记录] < 1 2
高端调试 » 软件调试 » Windows内核调试 » Re: WaitForSingleObject导致BSOD?

 
Legal Notice Privacy Statement Corporate Governance Corporate Governance
(C)2004-2017 ADVDBG.ORG All Rights Reserved.