?
Solved

Windows XP Blue Screen Issues.

Posted on 2010-01-13
9
Medium Priority
?
654 Views
Last Modified: 2012-05-08
I have a windows XP laptop that I cannot seem to figure out what is causing persistent Blue Screens.  Following is the analysis from the crash dump:

1: 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: 84673008, Address of the IRP
Arg2: 00001bc0
Arg3: 00000000
Arg4: 00000000

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


IRP_ADDRESS:  84673008

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x44

PROCESS_NAME:  csrss.exe

LAST_CONTROL_TRANSFER:  from 00000000 to 804f9f43

STACK_TEXT:  
f60aed94 00000000 00000023 00000003 00000002 nt!_woutput+0x414


STACK_COMMAND:  kb

FOLLOWUP_IP:
nt!_woutput+414
804f9f43 5d              pop     ebp

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!_woutput+414

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4a784394

FAILURE_BUCKET_ID:  0x44_nt!_woutput+414

BUCKET_ID:  0x44_nt!_woutput+414

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

Any help?  Attached is the mini-dump.
Mini011210-01.dmp
0
Comment
Question by:Shearers
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 2
  • 2
9 Comments
 
LVL 3

Expert Comment

by:rixlabs
ID: 26303767
Hi,

try this to verify the integrity of your's RAM
http://hcidesign.com/memtest/

0
 

Author Comment

by:Shearers
ID: 26304006
Memory test ran with no errors detected.
0
 
LVL 3

Expert Comment

by:rixlabs
ID: 26304201
to exclude harware problem you can try to use a Live distro of linux and try to stress you machine.
0
Ransomware-A Revenue Bonanza for Service Providers

Ransomware – malware that gets on your customers’ computers, encrypts their data, and extorts a hefty ransom for the decryption keys – is a surging new threat.  The purpose of this eBook is to educate the reader about ransomware attacks.

 

Author Comment

by:Shearers
ID: 26304264
OK, so you must have missed the crashdump, which points to a driver issue?
0
 
LVL 22

Accepted Solution

by:
optoma earned 1500 total points
ID: 26304295
That minidump points to the video driver. Get the latest chipset drivers and/or graphics card drivers.

Upload two other recent minidump files to confirm that they all the same.
0
 

Author Comment

by:Shearers
ID: 26306341
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: 84c96008, Address of the IRP
Arg2: 00000d64
Arg3: 00000000
Arg4: 00000000

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


IRP_ADDRESS:  84c96008

CUSTOMER_CRASH_COUNT:  4

DEFAULT_BUCKET_ID:  COMMON_SYSTEM_FAULT

BUGCHECK_STR:  0x44

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 00000000 to 804f9f43

STACK_TEXT:  
f7a1dd1c 00000000 00000044 84c96008 00000d64 nt!_woutput+0x414


STACK_COMMAND:  kb

FOLLOWUP_IP:
nt!_woutput+414
804f9f43 5d              pop     ebp

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nt!_woutput+414

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4a784394

FAILURE_BUCKET_ID:  0x44_nt!_woutput+414

BUCKET_ID:  0x44_nt!_woutput+414

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

Author Comment

by:Shearers
ID: 26306353
1: 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: 86163cd8, Address of the IRP
Arg2: 00000d64
Arg3: 00000000
Arg4: 00000000

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


IRP_ADDRESS:  86163cd8

CUSTOMER_CRASH_COUNT:  3

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0x44

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 80520824 to 8053767a

STACK_TEXT:  
f7234cd4 80520824 00000044 86163cd8 00000d64 nt!MiRemoveUnusedSegments+0x3e3
f7234d0c f76f299e 00000000 86163cd8 86163cd8 nt!MiSetSystemCodeProtection+0x148
f7234d20 805184c9 861f8030 86163cd8 861f20e0 usbhub!USBH_PortIdleNotificationCancelRoutine+0xa2
f7234d38 f77128a0 86163cd8 861415d0 861f20e0 nt!KiNpxFrameToEm87State+0x62
WARNING: Stack unwind information not available. Following frames may be wrong.
f7234d58 f7712b59 001f20e0 861f2028 f7234d7c tosrfusb+0x68a0
f7234d68 8056df51 861f2028 861415d0 8056a5fc tosrfusb+0x6b59
f7234d7c 804e23b5 861415d0 00000000 861a8020 nt!RtlCompareUnicodeString+0x44
f7234dac 80575723 861415d0 00000000 00000000 nt!LsapPort+0x41
f7234db0 861415d0 00000000 00000000 00000000 nt!PsRevertThreadToSelf+0x1
f7234ddc 804ec6d9 804e22f1 80000001 00000000 0x861415d0
00000000 00000000 00000000 00000000 00000000 nt!Magic86400000+0x201


STACK_COMMAND:  kb

FOLLOWUP_IP:
tosrfusb+68a0
f77128a0 ??              ???

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  tosrfusb+68a0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: tosrfusb

IMAGE_NAME:  tosrfusb.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  44896c2e

FAILURE_BUCKET_ID:  0x44_tosrfusb+68a0

BUCKET_ID:  0x44_tosrfusb+68a0

Followup: MachineOwner
---------
0
 
LVL 22

Expert Comment

by:optoma
ID: 26308518
Sorry, attach minidumps (*.dmp)
0
 

Author Closing Comment

by:Shearers
ID: 31676663
Problem resolved by re-installing drivers
0

Featured Post

Does Your Cloud Backup Use Blockchain Technology?

Blockchain technology has already revolutionized finance thanks to Bitcoin. Now it's disrupting other areas, including the realm of data protection. Learn how blockchain is now being used to authenticate backup files and keep them safe from hackers.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Can I legally transfer my OEM version of Windows to another PC?  (AKA - Can I put a new systemboard in my OEM PC?) Few of us are both IT and legal experts but we all have our own views of Microsoft's licensing rules and how they apply.  There are…
Migration of Exchange mailbox can be done with the ExProfre.exe tool. But at times, when the ExProfre.exe tool migrates the Exchange Server user profile, it results in numerous synchronization problems. Synchronization error messages appear in the e…
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…
In this video we outline the Physical Segments view of NetCrunch network monitor. By following this brief how-to video, you will be able to learn how NetCrunch visualizes your network, how granular is the information collected, as well as where to f…
Suggested Courses
Course of the Month8 days, 8 hours left to enroll

764 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question