问题描述
您好,
a对使用
IcmpCreateFile()的应用程序有一种奇怪的行为, IcmpSendEcho()和我 用于搜索设备的cmpCloseHandle()。此代码同时用于10个线程:
int ping(char *pstrHost, int to)
{
HANDLE hIcmpFile;
unsigned long ipaddr;
DWORD dwRetVal;
char SendData[] = "PING TEST";
BYTE ReplyBuffer[40];
LPHOSTENT lpHost;
lpHost = gethostbyname(pstrHost);
ipaddr = *((u_long FAR *) (lpHost->h_addr));
if((hIcmpFile = IcmpCreateFile()) == INVALID_HANDLE_VALUE)
return -1;
dwRetVal = IcmpSendEcho(hIcmpFile,
ipaddr, SendData, sizeof(SendData), NULL,
ReplyBuffer, sizeof(ReplyBuffer), to);
IcmpCloseHandle(hIcmpFile);
return (dwRetVal > 0)?1:-1;
}
当我调试这个应用程序时,我有时会得到一个BOD。这是一个崩溃转储:
When I debug this application I get sometimes a BOD. Here is a crash-dump:
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: SRV*C:/symbols*http://msdl.microsoft.com/download/symbols;C:\Symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff800`03e1e000 PsLoadedModuleList = 0xfffff800`04061670
Debug session time: Wed Jul 3 11:56:32.695 2013 (UTC + 2:00)
System Uptime: 0 days 0:35:59.918
Loading Kernel Symbols
...............................................................
................................................................
..................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 000007ff`fffdf018). Type ".hh dbgerr001" for details
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck CB, {fffff8800168b385, 0, fffffa8003854690, 5}
Probably caused by : tcpip.sys ( tcpip!Ipv4SetEchoRequestCreate+345 )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS (cb)
Caused by a driver not cleaning up completely after an I/O.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff8800168b385, The calling address in the driver that locked the pages or if the
IO manager locked the pages this points to the dispatch routine of
the top driver on the stack to which the IRP was sent.
Arg2: 0000000000000000, The caller of the calling address in the driver that locked the
pages. If the IO manager locked the pages this points to the device
object of the top driver on the stack to which the IRP was sent.
Arg3: fffffa8003854690, A pointer to the MDL containing the locked pages.
Arg4: 0000000000000005, The number of locked pages.
Debugging Details:
------------------
FAULTING_IP:
tcpip!Ipv4SetEchoRequestCreate+345
fffff880`0168b385 c644243401 mov byte ptr [rsp+34h],1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xCB
PROCESS_NAME: EmpProcMon.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff800041ce96f to fffff80003e93c00
STACK_TEXT:
fffff880`06a25a38 fffff800`041ce96f : 00000000`000000cb fffff880`0168b385 00000000`00000000 fffffa80`03854690 : nt!KeBugCheckEx
fffff880`06a25a40 fffff800`0414d677 : fffffa80`07146750 fffffa80`03545b20 fffffa80`00000000 fffffa80`00000000 : nt! ?? ::NNGAKEGL::`string'+0x17dbc
fffff880`06a25a80 fffff800`03e9ce44 : 00000000`00000000 fffffa80`06a45b30 fffffa80`07146720 fffffa80`039959b0 : nt!PspProcessDelete+0x177
fffff880`06a25ae0 fffff800`0418c2d4 : fffffa80`06a45b30 00000000`00000000 fffffa80`06b2f750 00000000`00000000 : nt!ObfDereferenceObject+0xd4
fffff880`06a25b40 fffff800`0418c884 : 00000000`00000170 fffffa80`06a45b30 fffff8a0`05498470 00000000`00000170 : nt!ObpCloseHandleTableEntry+0xc4
fffff880`06a25bd0 fffff800`03e92e93 : fffffa80`06b2f750 fffff880`06a25ca0 00000000`00000000 fffffa80`06a658e0 : nt!ObpCloseHandle+0x94
fffff880`06a25c20 00000000`779b140a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0264fb58 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x779b140a
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_IP:
tcpip!Ipv4SetEchoRequestCreate+345
fffff880`0168b385 c644243401 mov byte ptr [rsp+34h],1
SYMBOL_NAME: tcpip!Ipv4SetEchoRequestCreate+345
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: tcpip
IMAGE_NAME: tcpip.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 50e4f6f4
FAILURE_BUCKET_ID: X64_0xCB_tcpip!Ipv4SetEchoRequestCreate+345
BUCKET_ID: X64_0xCB_tcpip!Ipv4SetEchoRequestCreate+345
Followup: MachineOwner
---------
它看起来像tcpip.sys里面有问题。
我发现撞击后才发现崩溃visualstudio调试器内部的断点。
It looks, like there is a problem inside of tcpip.sys.
I noticed the crash only after hitting a breakpoint inside of the visualstudio debugger.
我创建了这个函数,因为我需要一个"ping"。没有管理员权限。
I created this function because I need a "ping" without admin rights.
再见
Uwe
Bye
Uwe
推荐答案
no我不等,因为通常运行时lib会在终止主线程后关闭所有打开的句柄。
no I don't wait, because normally the runtime lib closes all open handles afer terminating the main thread.
用户程序在任何时候都不能产生BOD。
And at no time a user program should be able to produce a BOD.
再见b $ b Uwe
Bye
Uwe
这篇关于tcpip.sys崩溃的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!