MULTIPLE_IRP_COMPLETE_REQUESTS (44) blue screens recently.


A

Ant

Hello.

I am helping figuring a client's old Dell Optiplex GX260's old Windows
2000 SP4 that is blue screening randomly with
"MULTIPLE_IRP_COMPLETE_REQUESTS (44)" crashes recently (a few days ago).

I checked the rear fan that is blowing warm air, inside looked OK and
clean. I don't think it is overheating. I am not sure what's going on.

He hasn't changed any drivers, hardwares, etc. Weird stuff. Maybe PC is
falling apart somewhere since it's old?

I did get the memory mini-dumps and I analyzed them (no symbols though
and only using
srv*c:\symbols\*http://msdl.microsoft.com/download/symbols) via the
latest WinDbg version. Here's an example from the latest one:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [E:\dl\Mini082109-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is:
srv*c:\symbols\*http://msdl.microsoft.com/download/symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for
ntoskrnl.exe
Windows 2000 Kernel Version 2195 (Service Pack 4) MP (2 procs) Free x86
compatible
Machine Name:
Kernel base = 0x80400000 PsLoadedModuleList = 0x80485b80
Debug session time: Fri Aug 21 00:12:39.625 2009 (GMT-7)
System Uptime: not available
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for
ntoskrnl.exe
Loading Kernel Symbols
................................................................
.................................................................
......
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 44, {81ca6008, d39, 0, 0}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntoskrnl.exe ( nt+1f004 )

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

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

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: 81ca6008, Address of the IRP
Arg2: 00000d39
Arg3: 00000000
Arg4: 00000000

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload'
to set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: 80400000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 45ec3c8f

IRP_ADDRESS: 81ca6008

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

LAST_CONTROL_TRANSFER: from 00000000 to 8041f004

STACK_TEXT:
80475e30 00000000 81ca6008 00000d39 00000000 nt+0x1f004


STACK_COMMAND: kb

FOLLOWUP_IP:
nt+1f004
8041f004 ?? ???

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt+1f004

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

BUCKET_ID: WRONG_SYMBOLS

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

0: kd> lmvm nt
start end module name
80400000 805a2940 nt T (no symbols)
Loaded symbol image file: ntoskrnl.exe
Image path: ntoskrnl.exe
Image name: ntoskrnl.exe
Timestamp: Mon Mar 05 07:51:43 2007 (45EC3C8F)
CheckSum: 001AB628
ImageSize: 001A2940
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Any ideas? Thank you in advance. :)
--
* <-- Tribble ... *********************** <-- Tribbles imitating ants
(unknown author)
/\___/\
/ /\ /\ \ Phil/Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Nuke ANT from e-mail address: (e-mail address removed)
( ) or (e-mail address removed)
Ant is currently not listening to any songs on his home computer.
 
Ad

Advertisements

D

Dave Patrick

This article may help.

http://support.microsoft.com/default.aspx/kb/311503


--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect


Ant said:
Hello.

I am helping figuring a client's old Dell Optiplex GX260's old Windows
2000 SP4 that is blue screening randomly with
"MULTIPLE_IRP_COMPLETE_REQUESTS (44)" crashes recently (a few days ago).

I checked the rear fan that is blowing warm air, inside looked OK and
clean. I don't think it is overheating. I am not sure what's going on.

He hasn't changed any drivers, hardwares, etc. Weird stuff. Maybe PC is
falling apart somewhere since it's old?

I did get the memory mini-dumps and I analyzed them (no symbols though and
only using srv*c:\symbols\*http://msdl.microsoft.com/download/symbols) via
the latest WinDbg version. Here's an example from the latest one:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [E:\dl\Mini082109-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is:
srv*c:\symbols\*http://msdl.microsoft.com/download/symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for
ntoskrnl.exe
Windows 2000 Kernel Version 2195 (Service Pack 4) MP (2 procs) Free x86
compatible
Machine Name:
Kernel base = 0x80400000 PsLoadedModuleList = 0x80485b80
Debug session time: Fri Aug 21 00:12:39.625 2009 (GMT-7)
System Uptime: not available
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for
ntoskrnl.exe
Loading Kernel Symbols
...............................................................
................................................................
.....
Loading User Symbols
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 44, {81ca6008, d39, 0, 0}

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntoskrnl.exe ( nt+1f004 )

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

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

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find
because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: 81ca6008, Address of the IRP
Arg2: 00000d39
Arg3: 00000000
Arg4: 00000000

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to
set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: 80400000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 45ec3c8f

IRP_ADDRESS: 81ca6008

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x44

LAST_CONTROL_TRANSFER: from 00000000 to 8041f004

STACK_TEXT:
80475e30 00000000 81ca6008 00000d39 00000000 nt+0x1f004


STACK_COMMAND: kb

FOLLOWUP_IP:
nt+1f004
8041f004 ?? ???

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt+1f004

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

BUCKET_ID: WRONG_SYMBOLS

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

0: kd> lmvm nt
start end module name
80400000 805a2940 nt T (no symbols)
Loaded symbol image file: ntoskrnl.exe
Image path: ntoskrnl.exe
Image name: ntoskrnl.exe
Timestamp: Mon Mar 05 07:51:43 2007 (45EC3C8F)
CheckSum: 001AB628
ImageSize: 001A2940
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Any ideas? Thank you in advance. :)
--
* <-- Tribble ... *********************** <-- Tribbles imitating ants
(unknown author)
/\___/\
/ /\ /\ \ Phil/Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Nuke ANT from e-mail address: (e-mail address removed)
( ) or (e-mail address removed)
Ant is currently not listening to any songs on his home computer.
 
A

Ant


Thanks. I already have
srv*c:\symbols\*http://msdl.microsoft.com/download/symbols configured. I
wonder if MS pulled its Windows 2000/W2K SP4 symbols off its server
since this OS is very old. However, it is still supported and updated by
MS. :/

I CC'ed microsoft.public.windbg to see if anyone knows too.
--
"Look at them, fighting like ants. The fate's waiting them." --Kane in
Command & Conquer 3: Tiberium Wars
/\___/\
/ /\ /\ \ Phil/Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Nuke ANT from e-mail address: (e-mail address removed)
( ) or (e-mail address removed)
Ant is currently not listening to any songs on his home computer.
 
A

Ant


Thanks. I wonder why WinDbg didn't see it remotely. Oh well.
--
"Be thine enemy an ant, see in him an elephant." --Turkish Proverb
/\___/\
/ /\ /\ \ Phil/Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Nuke ANT from e-mail address: (e-mail address removed)
( ) or (e-mail address removed)
Ant is currently not listening to any songs on his home computer.
 
Ad

Advertisements

Y

yuhong

Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Again what you are missing is NOT the symbols itself, but the
executable file that has the data needed to look up them on MS's
symbol server. Go get the copy of NTOSKRNL.EXE from the crashing
machine, set image search path to where you put it, then retry.
 
Ad

Advertisements


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top