我有一个机器突然bsod了,我全部内存转储了,用windbg打开,发现应用层调用WaitForSingleObject导致内核出错
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbolsExecutable search path is: Windows Server 2003 Kernel Version 3790 (Service Pack 1) MP (2 procs) Free x86 compatibleProduct: Server, suite: Enterprise TerminalServer SingleUserTSBuilt by: 3790.srv03_sp1_rtm.050324-1447Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8Debug session time: Wed Feb 4 09:11:55.328 2009 (GMT+8)System Uptime: 0 days 0:17:40.906Loading Kernel Symbols.................................................................................................Loading User SymbolsPEB is paged out (Peb.Ldr = 7ffd900c). Type ".hh dbgerr001" for detailsLoading unloaded module list..................******************************************************************************** ** Bugcheck Analysis ** ********************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1A, {3452, 1099221, c088376c, 0}
Probably caused by : memory_corruption ( nt!MiDeleteAddressesInWorkingSet+155 )
Followup: MachineOwner---------
1: 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: 01099221Arg3: c088376cArg4: 00000000
Debugging Details:------------------
BUGCHECK_STR: 0x1a_3452
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: notify.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8084c103 to 80827451
STACK_TEXT: b6210a8c 8084c103 0000001a 00003452 01099221 nt!KeBugCheckEx+0x1bb6210c48 8084c24d 88f0ad88 88f0ad88 00000000 nt!MiDeleteAddressesInWorkingSet+0x155b6210c68 8094b539 88f0afb0 88f977a8 00000001 nt!MmCleanProcessAddressSpace+0x111b6210cf0 8094b5b7 00000001 b6210d4c 8082d8b8 nt!PspExitThread+0x5f1b6210cfc 8082d8b8 88f977a8 b6210d48 b6210d3c nt!PsExitSpecialApc+0x1db6210d4c 80888cd4 00000001 00000000 b6210d64 nt!KiDeliverApc+0x1aeb6210d4c 7c95ed54 00000001 00000000 b6210d64 nt!KiServiceExit+0x56WARNING: Frame IP not in any known module. Following frames may be wrong.014ef81c 7c952124 7c82baa8 00000ef4 00000000 0x7c95ed54014ef890 7c82ba12 00000ef4 000493e0 00000000 0x7c952124014ef8a4 0065dbb4 00000ef4 000493e0 ffffffff 0x7c82ba12014ef97c 0065e43b 000493e0 00000000 00ec5168 0x65dbb4014ef9b0 0065e37f 000493e0 00000000 00ec5168 0x65e43b014ef9e8 0065e1fa 00ec54f0 000493e0 00ec54e8 0x65e37f014efa08 0065810e 00ec54f0 000493e0 00000000 0x65e1fa014efa3c 0050373a 000493e0 00000000 00ec5168 0x65810e014eff2c 809a05fe 7ffdd000 00ec54a0 00000000 0x50373a014eff5c 0065a6af 00000000 00ec5168 00ec5168 nt!DbgkCreateThread+0x3ac014effa0 80a5762d 014effdc 006b8ca8 007370e8 0x65a6af014effa0 00000000 014effdc 006b8ca8 007370e8 hal!HalpApcInterrupt+0xcd
STACK_COMMAND: kb
FOLLOWUP_IP: nt!MiDeleteAddressesInWorkingSet+1558084c103 cc int 3
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: nt!MiDeleteAddressesInWorkingSet+155
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
DEBUG_FLR_IMAGE_TIMESTAMP: 42435b14
IMAGE_NAME: memory_corruption
FAILURE_BUCKET_ID: 0x1a_3452_nt!MiDeleteAddressesInWorkingSet+155
BUCKET_ID: 0x1a_3452_nt!MiDeleteAddressesInWorkingSet+155
Followup: MachineOwner---------1: kd> kvChildEBP RetAddr Args to Child b6210a8c 8084c103 0000001a 00003452 01099221 nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo])b6210c48 8084c24d 88f0ad88 88f0ad88 00000000 nt!MiDeleteAddressesInWorkingSet+0x155 (FPO: [Non-Fpo])b6210c68 8094b539 88f0afb0 88f977a8 00000001 nt!MmCleanProcessAddressSpace+0x111 (FPO: [Non-Fpo])b6210cf0 8094b5b7 00000001 b6210d4c 8082d8b8 nt!PspExitThread+0x5f1 (FPO: [Non-Fpo])b6210cfc 8082d8b8 88f977a8 b6210d48 b6210d3c nt!PsExitSpecialApc+0x1d (FPO: [Non-Fpo])b6210d4c 80888cd4 00000001 00000000 b6210d64 nt!KiDeliverApc+0x1ae (FPO: [Non-Fpo])b6210d4c 7c95ed54 00000001 00000000 b6210d64 nt!KiServiceExit+0x56 (FPO: [0,0] TrapFrame @ b6210d64)WARNING: Frame IP not in any known module. Following frames may be wrong.014ef81c 7c952124 7c82baa8 00000ef4 00000000 0x7c95ed54014ef890 7c82ba12 00000ef4 000493e0 00000000 0x7c952124014ef8a4 0065dbb4 00000ef4 000493e0 ffffffff 0x7c82ba12014ef97c 0065e43b 000493e0 00000000 00ec5168 0x65dbb4014ef9b0 0065e37f 000493e0 00000000 00ec5168 0x65e43b014ef9e8 0065e1fa 00ec54f0 000493e0 00ec54e8 0x65e37f014efa08 0065810e 00ec54f0 000493e0 00000000 0x65e1fa014efa3c 0050373a 000493e0 00000000 00ec5168 0x65810e014eff2c 809a05fe 7ffdd000 00ec54a0 00000000 0x50373a014eff5c 0065a6af 00000000 00ec5168 00ec5168 nt!DbgkCreateThread+0x3ac (FPO: [Non-Fpo])014effa0 80a5762d 014effdc 006b8ca8 007370e8 0x65a6af014effa0 00000000 014effdc 006b8ca8 007370e8 hal!HalpApcInterrupt+0xcd (FPO: [0,2] TrapFrame @ ffffffff)1: kd> .trap b6210d64ErrCode = 00000000eax=000000c0 ebx=00ec5168 ecx=00000000 edx=00000000 esi=00000ef4 edi=00000000eip=7c95ed54 esp=014ef820 ebp=014ef890 iopl=0 nv up ei ng nz ac pe cycs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297001b:7c95ed54 ?? ???1: kd> u 0x65a6af0065a6af ?? ??? ^ Memory access error in 'u 0x65a6af'1: kd> d 0x65a6af0065a6af ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
1: kd> .processImplicit process is now 88f0ad881: kd> !process 88f0ad88PROCESS 88f0ad88 SessionId: 0 Cid: 0d1c Peb: 7ffd9000 ParentCid: 0e58 DirBase: 7bb576c0 ObjectTable: 00000000 HandleCount: 0. Image: notify.exe VadRoot 88f2ba28 Vads 56 Clone 0 Private 30. Modified 589. Locked 0. DeviceMap e11cc388 Token e1f6c030 ElapsedTime 00:02:35.296 UserTime 00:00:00.000 KernelTime 00:00:00.046 QuotaPoolUsage[PagedPool] 37256 QuotaPoolUsage[NonPagedPool] 2240 Working Set Sizes (now,min,max) (136, 50, 345) (544KB, 200KB, 1380KB) PeakWorkingSetSize 1794 VirtualSize 25 Mb PeakVirtualSize 28 Mb PageFaultCount 1820 MemoryPriority BACKGROUND BasePriority 8 CommitCharge 311
THREAD 89d72300 Cid 0d1c.0e50 Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 1 Not impersonating DeviceMap e11cc388 Owning Process 88f0ad88 Image: notify.exe Wait Start TickCount 67898 Ticks: 0 Context Switch Count 20 UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x006b62f2 Start Address 0x7c82b5bb Stack Init b6211000 Current b62107dc Base b6211000 Limit b620e000 Call 0 Priority 10 BasePriority 8 PriorityDecrement 0 ChildEBP RetAddr b6210a8c 8084c103 nt!KeBugCheckEx+0x1b (FPO: [Non-Fpo]) b6210c48 8084c24d nt!MiDeleteAddressesInWorkingSet+0x155 (FPO: [Non-Fpo]) b6210c68 8094b539 nt!MmCleanProcessAddressSpace+0x111 (FPO: [Non-Fpo]) b6210cf0 8094b5b7 nt!PspExitThread+0x5f1 (FPO: [Non-Fpo]) b6210cfc 8082d8b8 nt!PsExitSpecialApc+0x1d (FPO: [Non-Fpo]) b6210d4c 80888cd4 nt!KiDeliverApc+0x1ae (FPO: [Non-Fpo]) b6210d4c 7c95ed54 nt!KiServiceExit+0x56 (FPO: [0,0] TrapFrame @ b6210d64)WARNING: Frame IP not in any known module. Following frames may be wrong. 014ef81c 7c952124 0x7c95ed54 014ef890 7c82ba12 0x7c952124 014ef8a4 0065dbb4 0x7c82ba12 014ef97c 0065e43b 0x65dbb4 014ef9b0 0065e37f 0x65e43b 014ef9e8 0065e1fa 0x65e37f 014efa08 0065810e 0x65e1fa 014efa3c 0050373a 0x65810e 014eff2c 809a05fe 0x50373a 014eff5c 0065a6af nt!DbgkCreateThread+0x3ac (FPO: [Non-Fpo]) 014effa0 80a5762d 0x65a6af 014effa0 00000000 hal!HalpApcInterrupt+0xcd (FPO: [0,2] TrapFrame @ ffffffff)
我ida打开notify.exe,发现0x65dbb4前正好是在执行WaitForSingleObject,然后就调用kernel32.dll和ntdll.dll里面了,这里有个小小疑惑,不过不影响大局,就是notify.exe没有pdb文件好理解,但为什么kernel32.dll和ntdll.dll里面为什么不能导出符号?
真正疑惑的是在内核执行怎么就出问题了,是peb被paged out了么?光看PEB is paged out 和d 0x65a6af这些线索似乎可以这样认为,但系统到底出什么问题啦?我该怎么理解内核执行WaitForSingleObject就走到了KiServiceExit?
APC 的流程是:
KeInitializeApc -> KeInsertQueueApc -> Ki...
KiServiceExit 从内核态返回用户态前调用 KiDeliverApc 去“投递”APC:
kd> u KiServiceExitnt!KiServiceExit:8082351e fa cli8082351f f6457202 test byte ptr [ebp+72h],280823523 7506 jne nt!KiServiceExit+0xd (8082352b)80823525 f6456c01 test byte ptr [ebp+6Ch],180823529 7458 je nt!KiServiceExit+0x65 (80823583)8082352b 8b1d24f1dfff mov ebx,dword ptr ds:[0FFDFF124h]80823531 c6435e00 mov byte ptr [ebx+5Eh],080823535 807b3e00 cmp byte ptr [ebx+3Eh],080823539 7448 je nt!KiServiceExit+0x65 (80823583)8082353b 8bdd mov ebx,ebp8082353d 894344 mov dword ptr [ebx+44h],eax80823540 c743503b000000 mov dword ptr [ebx+50h],3Bh80823547 c7433823000000 mov dword ptr [ebx+38h],23h8082354e c7433423000000 mov dword ptr [ebx+34h],23h80823555 c7433000000000 mov dword ptr [ebx+30h],08082355c b901000000 mov ecx,180823561 ff15d0108080 call dword ptr [nt!_imp_KfRaiseIrql (808010d0)]80823567 50 push eax80823568 fb sti80823569 53 push ebx8082356a 6a00 push 08082356c 6a01 push 18082356e e86d5a0000 call nt!KiDeliverApc (80828fe0)
楼主的 APC 显然是线程结束 APC,在清除工作集的时候蓝掉了。
我看了一下 2003 的 nt!MiDeleteAddressesInWorkingSet:
nt!MiDeleteAddressesInWorkingSet:8083520e 8bff mov edi,edi80835210 55 push ebp80835211 8bec mov ebp,esp80835213 81ec10010000 sub esp,110h80835219 a120878a80 mov eax,dword ptr [nt!MmWorkingSetList (808a8720)]8083521e 83601c00 and dword ptr [eax+1Ch],080835222 83a5f0feffff00 and dword ptr [ebp-110h],080835229 57 push edi8083522a 6a02 push 28083522c 8d88a0060000 lea ecx,[eax+6A0h]80835232 a120878a80 mov eax,dword ptr [nt!MmWorkingSetList (808a8720)]80835237 5f pop edi80835238 397808 cmp dword ptr [eax+8],edi8083523b 894dfc mov dword ptr [ebp-4],ecx8083523e 0f82b0000000 jb nt!MiDeleteAddressesInWorkingSet+0x128 (808352f4)80835244 53 push ebx80835245 56 push esi80835246 8b4dfc mov ecx,dword ptr [ebp-4]80835249 8b09 mov ecx,dword ptr [ecx]8083524b f6c101 test cl,18083524e 747c je nt!MiDeleteAddressesInWorkingSet+0x100 (808352cc)80835250 3b0d40e88980 cmp ecx,dword ptr [nt!MmHighestUserAddress (8089e840)]80835256 7374 jae nt!MiDeleteAddressesInWorkingSet+0x100 (808352cc)80835258 8bf1 mov esi,ecx8083525a c1ee0a shr esi,0Ah8083525d 81e6fcff3f00 and esi,3FFFFCh80835263 81ee00000040 sub esi,40000000h80835269 f60601 test byte ptr [esi],18083526c 0f8416830200 je nt!MiDeleteAddressesInWorkingSet+0x12d (8085d588)80835272 f6c502 test ch,280835275 750c jne nt!MiDeleteAddressesInWorkingSet+0x7d (80835283)80835277 8b4508 mov eax,dword ptr [ebp+8]8083527a 8b8010020000 mov eax,dword ptr [eax+210h]80835280 ff4818 dec dword ptr [eax+18h]80835283 8b5d08 mov ebx,dword ptr [ebp+8]80835286 81c3e8010000 add ebx,1E8h8083528c 53 push ebx8083528d 57 push edi8083528e e838a10000 call nt!MiReleaseWsle (8083f3cb)80835293 a120878a80 mov eax,dword ptr [nt!MmWorkingSetList (808a8720)]80835298 3b7804 cmp edi,dword ptr [eax+4]8083529b 0f82bb820200 jb nt!MiDeleteAddressesInWorkingSet+0x97 (8085d55c)808352a1 8b8df0feffff mov ecx,dword ptr [ebp-110h]808352a7 89b48df4feffff mov dword ptr [ebp+ecx*4-10Ch],esi808352ae 8b95f0feffff mov edx,dword ptr [ebp-110h]808352b4 8b0e mov ecx,dword ptr [esi]808352b6 898c9578ffffff mov dword ptr [ebp+edx*4-88h],ecx808352bd ff85f0feffff inc dword ptr [ebp-110h]808352c3 83bdf0feffff21 cmp dword ptr [ebp-110h],21h808352ca 7437 je nt!MiDeleteAddressesInWorkingSet+0xe5 (80835303)808352cc 8345fc04 add dword ptr [ebp-4],4808352d0 47 inc edi808352d1 3b7808 cmp edi,dword ptr [eax+8]808352d4 0f866cffffff jbe nt!MiDeleteAddressesInWorkingSet+0x38 (80835246)808352da 83bdf0feffff00 cmp dword ptr [ebp-110h],0808352e1 5e pop esi808352e2 5b pop ebx808352e3 740f je nt!MiDeleteAddressesInWorkingSet+0x128 (808352f4)808352e5 ff7508 push dword ptr [ebp+8]808352e8 8d85f0feffff lea eax,[ebp-110h]808352ee 50 push eax808352ef e849460100 call nt!MiDeletePteList (8084993d)808352f4 5f pop edi808352f5 c9 leave808352f6 c20400 ret 4808352f9 e821460100 call nt!MiSessionRemoveProcess (8084991f)808352fe 5e pop esi808352ff c9 leave80835300 c20400 ret 480835303 ff7508 push dword ptr [ebp+8]80835306 8d85f0feffff lea eax,[ebp-110h]8083530c 50 push eax8083530d e82b460100 call nt!MiDeletePteList (8084993d)80835312 e96c8d0000 jmp nt!MiDeleteAddressesInWorkingSet+0xf4 (8083e083)80835317 56 push esi80835318 e8b8cbffff call nt!CcDeleteMbcb (80831ed5)8083531d e91d7effff jmp nt!CcDeleteSharedCacheMap+0xd2 (8082d13f)80835322 90 nop80835323 90 nop80835324 90 nop80835325 90 nop80835326 90 nop80835327 90 nop80835328 ff ???80835329 ff ???8083532a ff ???8083532b ffaddf9480c0 jmp fword ptr [ebp-3F7F6B21h]80835331 df9480ffffffff fist word ptr [eax+eax*4-1]80835338 45 inc ebp80835339 e194 loope nt!MiDeleteAddressesInWorkingSet+0x103 (808352cf)8083533b 8058e194 sbb byte ptr [eax-1Fh],94h8083533f 80ffff cmp bh,0FFh80835342 ff ???80835343 ffd1 call ecx80835345 e394 jecxz nt!MiDeleteAddressesInWorkingSet+0x10f (808352db)80835347 80e4e3 and ah,0E3h8083534a 94 xchg eax,esp8083534b 80ffff cmp bh,0FFh8083534e ff ???8083534f ff89e394809c dec dword ptr [ecx-637F6B1Dh]80835355 e394 jecxz nt!MiDeleteAddressesInWorkingSet+0x11f (808352eb)80835357 80837e04000f84 add byte ptr [ebx+0F00047Eh],84h8083535e 9aa5ffffe9a0a5 call A5A0:E9FFFFA580835365 ff ???80835366 ff837dcc010f inc dword ptr [ebx+0F01CC7Dh]8083536c 845164 test byte ptr [ecx+64h],dl8083536f 0200 add al,byte ptr [eax]80835371 ff75ec push dword ptr [ebp-14h]80835374 ff75fc push dword ptr [ebp-4]80835377 e86a370000 call nt!MiInsertImageSectionObject (80838ae6)8083537c e92d9f0000 jmp nt!MmCreateSection+0x43c (8083f2ae)80835381 90 nop80835382 90 nop80835383 90 nop80835384 90 nop80835385 90 nop//// nt!MiDeleteAddressesInWorkingSet+155// 8084c103 cc int 3//kd> u nt!MiDeleteAddressesInWorkingSet+0x110nt!CcDeleteSharedCacheMap+0xd3:8083531e 1d7effff90 sbb eax,90FFFF7Eh80835323 90 nop80835324 90 nop80835325 90 nop80835326 90 nop80835327 90 nop80835328 ff ???我严重怀疑指针已经跑飞了... 原因不明。另,Bug Check 0x1A: MEMORY_MANAGEMENT 的参数只公开了 参数1 ? 我一会查下源码。The following parameters are displayed on the blue screen. 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: 01099221Arg3: c088376cArg4: 000000000x1 The fork clone block reference count is corrupt. (This only occurs on checked builds of Windows.) 0x3451 The PTEs of a kernel thread stack that has been swapped out are corrupted.
我来介绍一下市面上的源码。市面上有泄露的(部分) NT 和 2K 微软内核源码,缺点是某些数据结构变化了,且无法编译、调试。微软公开的 WRK 是可编译的,但是开源代码较少( http://advdbg.org/forums/1442/ShowPost.aspx ),且只对教育领域公开。KiSSinGGer 同学就曾经因为在 Blog 上张贴 WRK1.2v 源码包而被微软致信警告,我记得驱动开发网论坛上有 Znsoft 张贴的源码包 (我就纳闷了,微软为什么不警告马勇同学呢?)许多同学是有源码而没有完整的光盘,光盘长这个模样 (感谢南京大学-夏耐博士/老师):十七孔桥的结构的确很漂亮! 实际调试 WRK 是这样的:可以看到源码路径里 KdInitSystem 是没有相应源码的,这是为什么呢? 唉,微软还是舍不得公开呀...可是 Kd 模块多吸引人呀... 那怎么办? 只有反汇编、调试、外加参考老版本的源码喽:好了,不多说了,以免给论坛引起不必要的麻烦。
呵呵 跑题了。我再补充一些:MiDeleteAddressesInWorkingSet 的参数是进程 - 88f0ad88
VOIDMiDeleteAddressesInWorkingSet ( 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.
--*/
1: kd> .processImplicit process is now 88f0ad881: kd> !process 88f0ad88PROCESS 88f0ad88 SessionId: 0 Cid: 0d1c Peb: 7ffd9000 ParentCid: 0e58
Owning Process 88f0ad88 Image: notify.exeWait Start TickCount 67898 Ticks: 0Context Switch Count 20
大致判断为 notify.exe 结束的时候发生的蓝屏。所以,楼主尝试结束 notify.exe 进程了(或楼主的相应操作结束 notify.exe 进程了?)notify.exe 进程是什么?如果可以调试的话,用我的工具可以查出是谁结束的 notify.exe(http://advdbg.org/blogs/advdbg_system/articles/1217.aspx)如果楼主不是很着急的话,我可以帮你分析 Dump,因为我最近比较忙,新年刚来,全是事情。
根据下面的汇编,MmCleanProcessAddressSpace和MmCleanProcessAddressSpace的第一个参数都是PEPROCESS:
8050f9d9 8b7508 mov esi,dword ptr [ebp+8] ;MmCleanProcessAddressSpace入口把第一个参数放入ESI8050fb59 56 push esi8050fb5a e89f4b0900 call nt!MiDeleteAddressesInWorkingSet (805a46fe) ;调用MiDeleteAddressesInWorkingSet
也就说,这两个函数的参数应该是同一个值。现在不一样,有可能放在栈上的MmCleanProcessAddressSpace函数的参数被破坏了。
不管怎么样,应该可以肯定的是,这个BSOD是因为在notify.exe进程上下文中,执行MmCleanProcessAddressSpace删除notify.exe的进程空间时发生的,这是不合乎常规的。那么为什么会执行呢?现在看是因为那个APC。有可能是哪个坏蛋(或者发昏的好蛋:-))故意向notify.exe进程中queue了一个让其“自己剁自己脚”的APC。
建议执行下!apc看下系统中目前有哪些APC(也许已经看不到有问题这个了,但可以试试)。如果这个问题能复现,那么使用双机活动调试,会容易很多。
哪里可以下载这个DUMP么?王宇,如果有,可以上传一份给我
Raymond 老师 我也没有 DUMP 文件,我是看楼主贴出来的信息写的。楼主要是能上传一份就好了。我又看了一下代码,的确是这样:VOIDMmCleanProcessAddressSpace ( IN PEPROCESS Process ){ ...... // // Delete all the valid user mode addresses from the working set list. // At this point page faults are allowed on user space addresses but are // generally rare (would have to be an attached thread doing the // references). Faults are allowed on page tables for user space, which // requires that we keep the working set structure consistent until we // finally take it all down. //
MiDeleteAddressesInWorkingSet (Process); ......}但是栈上的信息显示,这两个值确实不同:b6210c48 8084c24d 88f0ad88 88f0ad88 00000000 nt!MiDeleteAddressesInWorkingSet+0x155b6210c68 8094b539 88f0afb0 88f977a8 00000001 nt!MmCleanProcessAddressSpace+0x111的确是栈上的一些东西被破坏了。就像张老师说的那样,这个问题如果能复现,用双机调试或 SoftICE,就会真相大白的。 ^_^