IRP Request BSOD error

So im getting a bsod from running webroot security scanner (its ok just running or updating) i booted into safe mode and ran
it again and no bsod.

I unplugged all external HDDs controllers ect, ive done windows update and have updated all my drivers.

I ran a cpu stability test and had no problems, i also do not get this problem even when running memory hungry and cpu hungry programs.

I've ran malwarebytes on a full scan and havent picked up any viruses ect.

So when i click run scanner it will run for about 30 seconds and then it will go to bsod and say irp error request then do a memory dump and the computer restarts itself

crash dump:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\012911-24772-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\symbols*
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`02e0d000 PsLoadedModuleList = 0xfffff800`0304ae50
Debug session time: Sat Jan 29 16:20:11.692 2011 (UTC + 10:00)
System Uptime: 3 days 22:52:50.363
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
* *
* Bugcheck Analysis *
* *

Use !analyze -v to get detailed debugging information.

BugCheck 44, {fffffa8008547d20, 1d7b, 0, 0}

Probably caused by : mrxsmb.sys ( mrxsmb!RxCeCompleteConnectRequest+363 )

Followup: MachineOwner

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

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.
Arg1: fffffa8008547d20, Address of the IRP
Arg2: 0000000000001d7b
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

IRP_ADDRESS: fffffa8008547d20

fffff880`06badb47 33d2 xor edx,edx






LAST_CONTROL_TRANSFER: from fffff80002eef301 to fffff80002e7d740

fffff880`031bcea8 fffff800`02eef301 : 00000000`00000044 fffffa80`08547d20 00000000`00001d7b 00000000`00000000 : nt!KeBugCheckEx
fffff880`031bceb0 fffff880`06badb47 : fffffa80`048e4140 fffffa80`048e4140 fffffa80`067df680 fffffa80`048e4140 : nt! ?? ::FNODOBFM::`string'+0x31aec
fffff880`031bcef0 fffff880`06bae32e : 00000000`00000000 00000000`0000c702 fffffa80`0a6f92b0 00000000`00000040 : mrxsmb!RxCeCompleteConnectRequest+0x363
fffff880`031bcf70 fffff880`06bae20c : 00000000`00000000 fffffa80`0a6f92b0 00000000`63437852 00000000`00000706 : mrxsmb!SmbWskAsynchronousConnectCompletionWorker+0x106
fffff880`031bd010 fffff800`02e7fd26 : fffffa80`07b5dae3 fffffa80`03a5e800 00000000`00000000 fffff880`031bcea8 : mrxsmb!SmbWskAsynchronousConnectCompletion+0xb8
fffff880`031bd060 fffff880`02c04d59 : 00000000`00000000 00000000`e0000002 fffffa80`07b5da10 00000000`00000000 : nt!IopfCompleteRequest+0x3a6
fffff880`031bd140 fffff880`02c6fb2e : 00000000`00000003 00000000`00000000 fffffa80`03b92900 fffffa80`0495cb90 : afd!WskProTLConnectComplete+0x109
fffff880`031bd200 fffff880`02c6fc5b : fffffa80`05951f30 00000000`00000003 00000000`00000000 fffff880`02d815a5 : afd!WskTdiConnectFinish+0x3e
fffff880`031bd230 fffff800`02e7fd26 : fffffa80`084c287b fffff880`01891caf 00000000`00000000 00000000`00000000 : afd!WskTdiCOMPConnect+0x1b
fffff880`031bd260 fffff880`02d86ced : fffffa80`07831001 fffffa80`07831002 00000000`00000000 00000000`00000000 : nt!IopfCompleteRequest+0x3a6
fffff880`031bd340 fffff880`01859ba3 : 00000000`00000000 fffffa80`0465d802 00000000`00000000 fffff880`01870121 : tdx!TdxConnectConnectionTlRequestComplete+0x1fd
fffff880`031bd3c0 fffff880`0186d568 : 00000000`00000010 fffff880`031bd760 00000000`00000001 fffff880`0186e8b2 : tcpip!TcpCreateAndConnectTcbComplete+0x233
fffff880`031bd4d0 fffff880`0187a334 : 00000000`00000020 fffffa80`00000000 fffffa80`03a5e800 fffffa80`068938e0 : tcpip!TcpTcbCarefulDatagram+0x7f8
fffff880`031bd680 fffff880`0187e86a : fffffa80`047b5f00 00000000`94dfe0a9 fffffa80`04656b50 00000000`00000000 : tcpip!TcpTcbReceive+0x694
fffff880`031bd830 fffff880`0187e3b7 : fffffa80`049c9458 fffffa80`03a5e800 00000000`00000000 fffff880`01861700 : tcpip!TcpMatchReceive+0x1fa
fffff880`031bd980 fffff880`018606c7 : fffffa80`03a5bd01 fffffa80`047bd9c7 fffffa80`047bbd01 00000000`00000000 : tcpip!TcpPreValidatedReceive+0x177
fffff880`031bda30 fffff880`01860799 : fffff880`031bdbb0 fffff880`0196e9a0 fffff880`031bdbc0 00000000`000e0082 : tcpip!IppDeliverListToProtocol+0x97
fffff880`031bdaf0 fffff880`01860c90 : fffffa80`038624b0 fffffa80`04388b00 00000000`00000000 fffff880`031bdbb0 : tcpip!IppProcessDeliverList+0x59
fffff880`031bdb60 fffff880`018377c2 : fffffa80`036f9b60 fffff880`00eae77d 00000000`00000000 fffff880`01972f90 : tcpip!IppReceiveHeaderBatch+0x231
fffff880`031bdc40 fffff800`03179c43 : fffffa80`0463c230 fffff800`030225f8 fffffa80`036f9b60 fffffa80`0468f9e0 : tcpip!IppLoopbackTransmit+0x72
fffff880`031bdc80 fffff800`02e8a961 : fffff800`03022500 fffff800`03179c20 fffffa80`036f9b60 00000000`00000000 : nt!IopProcessWorkItem+0x23
fffff880`031bdcb0 fffff800`03121c06 : 00000000`00000000 fffffa80`036f9b60 00000000`00000080 fffffa80`036df890 : nt!ExpWorkerThread+0x111
fffff880`031bdd40 fffff800`02e5bc26 : fffff880`02f63180 fffffa80`036f9b60 fffff880`02f6dfc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`031bdd80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16



SYMBOL_NAME: mrxsmb!RxCeCompleteConnectRequest+363



IMAGE_NAME: mrxsmb.sys


FAILURE_BUCKET_ID: X64_0x44_mrxsmb!RxCeCompleteConnectRequest+363

BUCKET_ID: X64_0x44_mrxsmb!RxCeCompleteConnectRequest+363

Followup: MachineOwner
7 answers Last reply
More about request bsod error
  1. it has to be the problem of the software, I used to get BSOD quite often like after 2-5 mins after just turning on my computer. It was because of the RAM, I had 4 GB RAM DDR2, but I only have 2 GB RAM and the extra DDR2 stick has gone for repairs .
    So, I am guessing that its the problem of the software you have (webroot security scanner)
  2. i just uninstalled it, obviously it was conflicting with something and causing
    it to crash
  3. Any idea what was causing it ?
  4. not much of an idea, looking through the dump it seemed it was conflicting with a driver for some reason and it worked in safe mode so im assuming that was true.

    only thing is, it never happened with anything else except that, so i guess i can live without it
  5. @dannyb87:

    Looks like this is a known Win2008R2 issue, which also has been seen on SP1. Have a look at my post here:

    Did you manage to find a reproduction scenario for this?

    You can follow that post for further info.

  6. i never actually got a solution, its the only thing ive ever ran that caused a BSOD, besides something being corrupted that ive fixed.
  7. Well, at least its fixed.
Ask a new question

Read More

Blue Screen Scanners Windows 7