RtlFillMemory BSOD

Hello,

Our USB device driver is having some blue screens happening during an initialization call that calls RtlFillMemory to fill in a struct passed down from user level.

Basically, the routine is as follows:

-User level application passes a struct as output buffer down into the driver via an IOCTL that uses METHOD_BUFFERED

-The driver reads some configuration data from the device and fills in the struct members. Struct members are pointers to user-allocated data buffers that are determined and allocated before the DeviceIoControl call is made.

The request then completes and the user level software uses the information provided.

This has always worked for us and has never been a problem except for with one recent customer. Their product internally uses two of our devices connected through a hub. We do have one of the customer’s products for testing and can easily reproduce the problem; what I’ve noticed is that the connection is quite poor between the customer product and the host, and that the device regularly connects and disconnects during use (use requires physical movement of the device). I believe this disconnection is probably the cause and point in time that the blue screen is happening, since it doesn’t happen if you set the device down. It also doesn’t happen when I plug in and enumerate the device initially either. The disconnection is happening between hub and host PC, not between the hub and our devices.

The blue screen occurs in a call to RtlFillMemory; it seems as though the destination pointer provided by the user level is invalidated. Does anyone have any idea why or how this could be happening?

Here’s the debug output:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff88008b1c533, Address of the instruction which caused the bugcheck
Arg3: fffff8800d586690, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
DriverName!doGetConfigInfo+bf3 [d:\path\ioctl.c @ 1913]
fffff880`08b1c533 f3aa rep stos byte ptr [rdi]

CONTEXT: fffff8800d586690 – (.cxr 0xfffff8800d586690)
rax=0000000000000000 rbx=fffffa800d033d20 rcx=000000000000002b
rdx=fffffa800c922640 rsi=fffffa800c9a1814 rdi=0000000022934e40
rip=fffff88008b1c533 rsp=fffff8800d587070 rbp=fffff8800d587490
r8=0000000000000001 r9=fffff80002b0b0a0 r10=0000000000000000
r11=fffff8800d586c18 r12=0000057ff2fcc2d8 r13=0000000000222060
r14=0000057ff3d073a8 r15=0000000000000058
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
DriverName!doGetConfigInfo+0xbf3:
fffff880`08b1c533 f3aa rep stos byte ptr [rdi]
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: astudio.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff88008b1a390 to fffff88008b1c533

STACK_TEXT:
fffff8800d587070 fffff88008b1a390 : fffffa800c315ef0 fffffa800c922640 fffff88008b1d650 fffff8800d5870a0 : DriverName!doGetConfigInfo+0xbf3 [d:\path\ioctl.c @ 1913]
fffff8800d587140 fffff88000e86f88 : 0000057ff3d073a8 0000057ff2fcc2d8 0000000000000058 0000000000000058 : DriverName!OsrFxEvtIoDeviceControl+0xb60 [d:\path\ioctl.c @ 538]
fffff8800d587450 fffff88000e8642f : fffffa800c2f8c00 fffffa8000000058 fffffa800c2f8c50 fffffa800c2f8c50 : Wdf01000!FxIoQueue::DispatchRequestToDriver+0x488
fffff8800d5874d0 fffff88000e8ae12 : fffffa800c2f8810 fffff88000e8e600 0000000000000000 fffffa800c2f8c50 : Wdf01000!FxIoQueue::DispatchEvents+0x66f
fffff8800d587550 fffff88000e8bcb4 : fffffa800d033d00 fffffa800d033d20 fffffa800c2fde80 0000000074617453 : Wdf01000!FxIoQueue::QueueRequestFromForward+0x23e
fffff8800d5875a0 fffff88000e8b836 : fffff8800d580000 fffffa800c315c40 fffff8800d587650 fffffa800d033d20 : Wdf01000!FxPkgIo::EnqueueRequest+0x2c0
fffff8800d587610 fffff88008b0e0d5 : fffffa800c315c40 fffffa800d033d20 0000057ff2fcc2d8 0000000000000000 : Wdf01000!imp_WdfDeviceEnqueueRequest+0x256
fffff8800d587690 fffff88008b0f1d2 : 0000057ff3cea3b8 0000057ff2fcc2d8 0000000000000101 0000000000000001 : DriverName!WdfDeviceEnqueueRequest+0x25 [c:\winddk\7600.16385.0\inc\wdf\kmdf\1.9\wdfdevice.h @ 3429]
fffff8800d5876c0 fffff88000e8b433 : 0000057ff3cea3b8 0000057ff2fcc2d8 0000000000000000 fffffa800d00c750 : DriverName!EvtIoInCallerContext+0x532 [d:\path\ioctl.c @ 2346]
fffff8800d5877b0 fffff88000e8b243 : fffffa800c2f8810 fffffa800d033d20 fffffa800c2f8c50 fffffa800d00c750 : Wdf01000!FxPkgIo::DispathToInCallerContextCallback+0xf3
fffff8800d5877e0 fffff88000e8a9da : fffffa800d033d20 fffffa800d00c750 fffff8800d587b60 fffffa800d00c750 : Wdf01000!FxPkgIo::Dispatch+0x413
fffff8800d587850 fffff88000e8aaa6 : fffffa800d00c750 fffff8800d587b60 fffffa800c300e10 0000000000000001 : Wdf01000!FxDevice::Dispatch+0x19a
fffff8800d587890 fffff80002debf37 : fffffa800c485310 fffff8800d587b60 fffffa800c485310 fffffa800d00c750 : Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff8800d5878d0 fffff80002dec796 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!IopXxxControlFile+0x607
fffff8800d587a00 fffff80002acce93 : fffffa800ceaf1a0 0000007fffffffff fffff8800d587a88 0000098000000000 : nt!NtDeviceIoControlFile+0x56
fffff8800d587a70 0000000076df138a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000001153cf18 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x76df138a

FOLLOWUP_IP:
DriverName!doGetConfigInfo+bf3 [d:\path\ioctl.c @ 1913]
fffff880`08b1c533 f3aa rep stos byte ptr [rdi]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: DriverName!doGetConfigInfo+bf3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: DriverName

IMAGE_NAME: DriverName.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51ea9b25

STACK_COMMAND: .cxr 0xfffff8800d586690 ; kb

FAILURE_BUCKET_ID: X64_0x3B_DriverName!doGetConfigInfo+bf3

BUCKET_ID: X64_0x3B_DriverName!doGetConfigInfo+bf3

Followup: MachineOwner

2: kd> lmvm DriverName
start end module name
fffff88008b0c000 fffff88008b22000 DriverName (private pdb symbols) p:\path\DriverName.pdb
Loaded symbol image file: DriverName.sys
Image path: \SystemRoot\System32\Drivers\DriverName.sys
Image name: DriverName.sys
Timestamp: Sat Jul 20 07:13:57 2013 (51EA9B25)
CheckSum: 0001A107
ImageSize: 00016000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

xxxxx@gmail.com wrote:

Basically, the routine is as follows:

-User level application passes a struct as output buffer down into the driver via an IOCTL that uses METHOD_BUFFERED

-The driver reads some configuration data from the device and fills in the struct members. Struct members are pointers to user-allocated data buffers that are determined and allocated before the DeviceIoControl call is made.

It has ALWAYS been a bad idea to have a kernel driver deal directly with
user-mode addresses, for exactly this reason. There’s no validation,
there’s no locking, there are no guarantees. The process might be
killed out from under you, and you go walking off into empty space.
This has worked for you by accident. This is the whole reason that
direct I/O exists, so you can let the I/O manager deal with locking down
the pages and mapping them into kernel space.

The blue screen occurs in a call to RtlFillMemory; it seems as though the destination pointer provided by the user level is invalidated. Does anyone have any idea why or how this could be happening?

The process might be dying. The memory might have been freed. A
malware process might have overwritten the memory and trashed the structure.

The BEST plan is for you to switch to direct I/O instead of passing
user-mode pointers at all, but I can already hear you complaining about
that. The next best plan is for you to use MmProbeAndLockPages in a
try/except block to make sure the memory stays valid.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Or you are not running in the context of the app since you are using a power managed queue which can alter the context. First and foremost, go with direct io if you can. It better yet, just make the output buffer as big as all the individual buffers put together and just write to diff offsets. If you can’t get away from embedded pointers, capture probe and lock them in EvtIoInCallerContext with wdfrequestprobeandlockuserbufferforread/write

d

Bent from my phone


From: Tim Robertsmailto:xxxxx
Sent: ?7/?26/?2013 1:01 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] RtlFillMemory BSOD

xxxxx@gmail.com wrote:
> Basically, the routine is as follows:
>
> -User level application passes a struct as output buffer down into the driver via an IOCTL that uses METHOD_BUFFERED
>
> -The driver reads some configuration data from the device and fills in the struct members. Struct members are pointers to user-allocated data buffers that are determined and allocated before the DeviceIoControl call is made.

It has ALWAYS been a bad idea to have a kernel driver deal directly with
user-mode addresses, for exactly this reason. There’s no validation,
there’s no locking, there are no guarantees. The process might be
killed out from under you, and you go walking off into empty space.
This has worked for you by accident. This is the whole reason that
direct I/O exists, so you can let the I/O manager deal with locking down
the pages and mapping them into kernel space.

> The blue screen occurs in a call to RtlFillMemory; it seems as though the destination pointer provided by the user level is invalidated. Does anyone have any idea why or how this could be happening?

The process might be dying. The memory might have been freed. A
malware process might have overwritten the memory and trashed the structure.

The BEST plan is for you to switch to direct I/O instead of passing
user-mode pointers at all, but I can already hear you complaining about
that. The next best plan is for you to use MmProbeAndLockPages in a
try/except block to make sure the memory stays valid.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

> Hello,

Our USB device driver is having some blue screens happening during an
initialization call that calls RtlFillMemory to fill in a struct passed
down from user level.

Basically, the routine is as follows:

-User level application passes a struct as output buffer down into the
driver via an IOCTL that uses METHOD_BUFFERED

-The driver reads some configuration data from the device and fills in the
struct members. Struct members are pointers to user-allocated data buffers
that are determined and allocated before the DeviceIoControl call is made.

There are so many things wrong with this idea that it is hard to say
something other than “rewrite this”. You can’t do that. Nobody cares if
the user buffers are allocated in user space before the call. It is
irrelevant beyond belief. The fact that you took the time to explain this
shows you have a very marginal understanding of how drivers work. By
sending user-mode addresses into the kernel, you have created a monster
that you may never manage to cut off all the heads of. Delete all the
source files and rewrite from scratch, without passing in ANY user-mode
addresses. Key here is that every one of those addresses must refer to
pages that are locked down, and for which you can get a kernel address.
And guess who has to learn to create MDLs and lock the memory down?
Right. You. You have created a driver wrier’s worst nightmare. Yes, it
can be done. Scott Noone, Peter Viscarola, and Tony Mason can do it.
Under sufficient duress, I might try to do it with a good chance of
success. But because you had to state the buffers were preallocated, the
chances that you will get it working in less time than it would take to
rewrite it correctly are very, very small. You are on the wrong place on
the learning curve. A design like this would have been rejected by an
experienced driver writer, because it adds MASSIVE complexity to the
driver for ZERO gain.

Note that te correct characterization is most definitely NOT “it has
always worked for us”. The correct characterization is “The right set of
conditions guaranteed to cause a BSOD which is unavoidable because of a
deeply flawed design were never encountered in our tests” There are no
“bugs” in your driver that cannot be fixed by a total rewrite.

I’m sorry this is not what you want to hear, but I’ve seen so many newbie
mistakes in product drivers that all I can do is try to remove such flawed
designs from the driver ecosystem.

Sometimes, extinction is the best thing that can happen to an ecosystem.
joe

The request then completes and the user level software uses the
information provided.

This has always worked for us and has never been a problem except for with
one recent customer. Their product internally uses two of our devices
connected through a hub. We do have one of the customer’s products for
testing and can easily reproduce the problem; what I’ve noticed is that
the connection is quite poor between the customer product and the host,
and that the device regularly connects and disconnects during use (use
requires physical movement of the device). I believe this disconnection is
probably the cause and point in time that the blue screen is happening,
since it doesn’t happen if you set the device down. It also doesn’t happen
when I plug in and enumerate the device initially either. The
disconnection is happening between hub and host PC, not between the hub
and our devices.

The blue screen occurs in a call to RtlFillMemory; it seems as though the
destination pointer provided by the user level is invalidated. Does anyone
have any idea why or how this could be happening?

Yep. Very simple. Bad design.
joe

Here’s the debug output:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff88008b1c533, Address of the instruction which caused the
bugcheck
Arg3: fffff8800d586690, Address of the context record for the exception
that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
DriverName!doGetConfigInfo+bf3 [d:\path\ioctl.c @ 1913]
fffff880`08b1c533 f3aa rep stos byte ptr [rdi]

CONTEXT: fffff8800d586690 – (.cxr 0xfffff8800d586690)
rax=0000000000000000 rbx=fffffa800d033d20 rcx=000000000000002b
rdx=fffffa800c922640 rsi=fffffa800c9a1814 rdi=0000000022934e40
rip=fffff88008b1c533 rsp=fffff8800d587070 rbp=fffff8800d587490
r8=0000000000000001 r9=fffff80002b0b0a0 r10=0000000000000000
r11=fffff8800d586c18 r12=0000057ff2fcc2d8 r13=0000000000222060
r14=0000057ff3d073a8 r15=0000000000000058
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b
efl=00010246
DriverName!doGetConfigInfo+0xbf3:
fffff880`08b1c533 f3aa rep stos byte ptr [rdi]
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: astudio.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff88008b1a390 to fffff88008b1c533

STACK_TEXT:
fffff8800d587070 fffff88008b1a390 : fffffa800c315ef0 fffffa800c922640
fffff88008b1d650 fffff8800d5870a0 : DriverName!doGetConfigInfo+0xbf3
[d:\path\ioctl.c @ 1913]
fffff8800d587140 fffff88000e86f88 : 0000057ff3d073a8 0000057ff2fcc2d8
0000000000000058 0000000000000058 :
DriverName!OsrFxEvtIoDeviceControl+0xb60 [d:\path\ioctl.c @ 538]
fffff8800d587450 fffff88000e8642f : fffffa800c2f8c00 fffffa8000000058
fffffa800c2f8c50 fffffa800c2f8c50 :
Wdf01000!FxIoQueue::DispatchRequestToDriver+0x488
fffff8800d5874d0 fffff88000e8ae12 : fffffa800c2f8810 fffff88000e8e600
0000000000000000 fffffa800c2f8c50 :
Wdf01000!FxIoQueue::DispatchEvents+0x66f
fffff8800d587550 fffff88000e8bcb4 : fffffa800d033d00 fffffa800d033d20
fffffa800c2fde80 0000000074617453 :
Wdf01000!FxIoQueue::QueueRequestFromForward+0x23e
fffff8800d5875a0 fffff88000e8b836 : fffff8800d580000 fffffa800c315c40
fffff8800d587650 fffffa800d033d20 :
Wdf01000!FxPkgIo::EnqueueRequest+0x2c0
fffff8800d587610 fffff88008b0e0d5 : fffffa800c315c40 fffffa800d033d20
0000057ff2fcc2d8 0000000000000000 :
Wdf01000!imp_WdfDeviceEnqueueRequest+0x256
fffff8800d587690 fffff88008b0f1d2 : 0000057ff3cea3b8 0000057ff2fcc2d8
0000000000000101 0000000000000001 :
DriverName!WdfDeviceEnqueueRequest+0x25
[c:\winddk\7600.16385.0\inc\wdf\kmdf\1.9\wdfdevice.h @ 3429]
fffff8800d5876c0 fffff88000e8b433 : 0000057ff3cea3b8 0000057ff2fcc2d8
0000000000000000 fffffa800d00c750 :
DriverName!EvtIoInCallerContext+0x532 [d:\path\ioctl.c @ 2346]
fffff8800d5877b0 fffff88000e8b243 : fffffa800c2f8810 fffffa800d033d20
fffffa800c2f8c50 fffffa800d00c750 :
Wdf01000!FxPkgIo::DispathToInCallerContextCallback+0xf3
fffff8800d5877e0 fffff88000e8a9da : fffffa800d033d20 fffffa800d00c750
fffff8800d587b60 fffffa800d00c750 : Wdf01000!FxPkgIo::Dispatch+0x413
fffff8800d587850 fffff88000e8aaa6 : fffffa800d00c750 fffff8800d587b60
fffffa800c300e10 0000000000000001 : Wdf01000!FxDevice::Dispatch+0x19a
fffff8800d587890 fffff80002debf37 : fffffa800c485310 fffff8800d587b60
fffffa800c485310 fffffa800d00c750 :
Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff8800d5878d0 fffff80002dec796 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!IopXxxControlFile+0x607
fffff8800d587a00 fffff80002acce93 : fffffa800ceaf1a0 0000007fffffffff
fffff8800d587a88 0000098000000000 : nt!NtDeviceIoControlFile+0x56
fffff8800d587a70 0000000076df138a : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000001153cf18 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : 0x76df138a

FOLLOWUP_IP:
DriverName!doGetConfigInfo+bf3 [d:\path\ioctl.c @ 1913]
fffff880`08b1c533 f3aa rep stos byte ptr [rdi]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: DriverName!doGetConfigInfo+bf3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: DriverName

IMAGE_NAME: DriverName.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51ea9b25

STACK_COMMAND: .cxr 0xfffff8800d586690 ; kb

FAILURE_BUCKET_ID: X64_0x3B_DriverName!doGetConfigInfo+bf3

BUCKET_ID: X64_0x3B_DriverName!doGetConfigInfo+bf3

Followup: MachineOwner

2: kd> lmvm DriverName
start end module name
fffff88008b0c000 fffff88008b22000 DriverName (private pdb symbols)
p:\path\DriverName.pdb
Loaded symbol image file: DriverName.sys
Image path: \SystemRoot\System32\Drivers\DriverName.sys
Image name: DriverName.sys
Timestamp: Sat Jul 20 07:13:57 2013 (51EA9B25)
CheckSum: 0001A107
ImageSize: 00016000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I thought of another good reason to kill of this design ASAP: think
“64-bit pointers” and “32-bit app running on Win64”. If you thought the
nightmare was bad before, this is where the horrible slimy creature crawls
out of the ocean and eats Tokyo. And you’re on the shore. Kill, Kill,
Kill. Bring out the nuclear annihilation beam.
joe

> Hello,
>
> Our USB device driver is having some blue screens happening during an
> initialization call that calls RtlFillMemory to fill in a struct passed
> down from user level.
>
> Basically, the routine is as follows:
>
> -User level application passes a struct as output buffer down into the
> driver via an IOCTL that uses METHOD_BUFFERED
>
> -The driver reads some configuration data from the device and fills in
> the
> struct members. Struct members are pointers to user-allocated data
> buffers
> that are determined and allocated before the DeviceIoControl call is
> made.

There are so many things wrong with this idea that it is hard to say
something other than “rewrite this”. You can’t do that. Nobody cares if
the user buffers are allocated in user space before the call. It is
irrelevant beyond belief. The fact that you took the time to explain this
shows you have a very marginal understanding of how drivers work. By
sending user-mode addresses into the kernel, you have created a monster
that you may never manage to cut off all the heads of. Delete all the
source files and rewrite from scratch, without passing in ANY user-mode
addresses. Key here is that every one of those addresses must refer to
pages that are locked down, and for which you can get a kernel address.
And guess who has to learn to create MDLs and lock the memory down?
Right. You. You have created a driver wrier’s worst nightmare. Yes, it
can be done. Scott Noone, Peter Viscarola, and Tony Mason can do it.
Under sufficient duress, I might try to do it with a good chance of
success. But because you had to state the buffers were preallocated, the
chances that you will get it working in less time than it would take to
rewrite it correctly are very, very small. You are on the wrong place on
the learning curve. A design like this would have been rejected by an
experienced driver writer, because it adds MASSIVE complexity to the
driver for ZERO gain.

Note that te correct characterization is most definitely NOT “it has
always worked for us”. The correct characterization is “The right set of
conditions guaranteed to cause a BSOD which is unavoidable because of a
deeply flawed design were never encountered in our tests” There are no
“bugs” in your driver that cannot be fixed by a total rewrite.

I’m sorry this is not what you want to hear, but I’ve seen so many newbie
mistakes in product drivers that all I can do is try to remove such flawed
designs from the driver ecosystem.

Sometimes, extinction is the best thing that can happen to an ecosystem.
joe
>
> The request then completes and the user level software uses the
> information provided.
>
> This has always worked for us and has never been a problem except for
> with
> one recent customer. Their product internally uses two of our devices
> connected through a hub. We do have one of the customer’s products for
> testing and can easily reproduce the problem; what I’ve noticed is that
> the connection is quite poor between the customer product and the host,
> and that the device regularly connects and disconnects during use (use
> requires physical movement of the device). I believe this disconnection
> is
> probably the cause and point in time that the blue screen is happening,
> since it doesn’t happen if you set the device down. It also doesn’t
> happen
> when I plug in and enumerate the device initially either. The
> disconnection is happening between hub and host PC, not between the hub
> and our devices.
>
> The blue screen occurs in a call to RtlFillMemory; it seems as though
> the
> destination pointer provided by the user level is invalidated. Does
> anyone
> have any idea why or how this could be happening?
>
Yep. Very simple. Bad design.
joe
>
>
>
> Here’s the debug output:
>
>
> SYSTEM_SERVICE_EXCEPTION (3b)
> An exception happened while executing a system service routine.
> Arguments:
> Arg1: 00000000c0000005, Exception code that caused the bugcheck
> Arg2: fffff88008b1c533, Address of the instruction which caused the
> bugcheck
> Arg3: fffff8800d586690, Address of the context record for the exception
> that caused the bugcheck
> Arg4: 0000000000000000, zero.
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
> referenced memory at 0x%08lx. The memory could not be %s.
>
> FAULTING_IP:
> DriverName!doGetConfigInfo+bf3 [d:\path\ioctl.c @ 1913]
> fffff88008b1c533 f3aa rep stos byte ptr [rdi] \> \> CONTEXT: fffff8800d586690 -- (.cxr 0xfffff8800d586690) \> rax=0000000000000000 rbx=fffffa800d033d20 rcx=000000000000002b \> rdx=fffffa800c922640 rsi=fffffa800c9a1814 rdi=0000000022934e40 \> rip=fffff88008b1c533 rsp=fffff8800d587070 rbp=fffff8800d587490 \> r8=0000000000000001 r9=fffff80002b0b0a0 r10=0000000000000000 \> r11=fffff8800d586c18 r12=0000057ff2fcc2d8 r13=0000000000222060 \> r14=0000057ff3d073a8 r15=0000000000000058 \> iopl=0 nv up ei pl zr na po nc \> cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b \> efl=00010246 \> DriverName!doGetConfigInfo+0xbf3: \> fffff88008b1c533 f3aa rep stos byte ptr [rdi]
> Resetting default scope
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> BUGCHECK_STR: 0x3B
>
> PROCESS_NAME: astudio.exe
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from fffff88008b1a390 to fffff88008b1c533
>
> STACK_TEXT:
> fffff8800d587070 fffff88008b1a390 : fffffa800c315ef0 \> fffffa800c922640
> fffff88008b1d650 fffff8800d5870a0 : DriverName!doGetConfigInfo+0xbf3
> [d:\path\ioctl.c @ 1913]
> fffff8800d587140 fffff88000e86f88 : 0000057ff3d073a8 \> 0000057ff2fcc2d8
> 0000000000000058 0000000000000058 :
> DriverName!OsrFxEvtIoDeviceControl+0xb60 [d:\path\ioctl.c @ 538]
> fffff8800d587450 fffff88000e8642f : fffffa800c2f8c00 \> fffffa8000000058
> fffffa800c2f8c50 fffffa800c2f8c50 :
> Wdf01000!FxIoQueue::DispatchRequestToDriver+0x488
> fffff8800d5874d0 fffff88000e8ae12 : fffffa800c2f8810 \> fffff88000e8e600
> 0000000000000000 fffffa800c2f8c50 :
> Wdf01000!FxIoQueue::DispatchEvents+0x66f
> fffff8800d587550 fffff88000e8bcb4 : fffffa800d033d00 \> fffffa800d033d20
> fffffa800c2fde80 0000000074617453 :
> Wdf01000!FxIoQueue::QueueRequestFromForward+0x23e
> fffff8800d5875a0 fffff88000e8b836 : fffff8800d580000 \> fffffa800c315c40
> fffff8800d587650 fffffa800d033d20 :
> Wdf01000!FxPkgIo::EnqueueRequest+0x2c0
> fffff8800d587610 fffff88008b0e0d5 : fffffa800c315c40 \> fffffa800d033d20
> 0000057ff2fcc2d8 0000000000000000 :
> Wdf01000!imp_WdfDeviceEnqueueRequest+0x256
> fffff8800d587690 fffff88008b0f1d2 : 0000057ff3cea3b8 \> 0000057ff2fcc2d8
> 0000000000000101 0000000000000001 :
> DriverName!WdfDeviceEnqueueRequest+0x25
> [c:\winddk\7600.16385.0\inc\wdf\kmdf\1.9\wdfdevice.h @ 3429]
> fffff8800d5876c0 fffff88000e8b433 : 0000057ff3cea3b8 \> 0000057ff2fcc2d8
> 0000000000000000 fffffa800d00c750 :
> DriverName!EvtIoInCallerContext+0x532 [d:\path\ioctl.c @ 2346]
> fffff8800d5877b0 fffff88000e8b243 : fffffa800c2f8810 \> fffffa800d033d20
> fffffa800c2f8c50 fffffa800d00c750 :
> Wdf01000!FxPkgIo::DispathToInCallerContextCallback+0xf3
> fffff8800d5877e0 fffff88000e8a9da : fffffa800d033d20 \> fffffa800d00c750
> fffff8800d587b60 fffffa800d00c750 : Wdf01000!FxPkgIo::Dispatch+0x413
> fffff8800d587850 fffff88000e8aaa6 : fffffa800d00c750 \> fffff8800d587b60
> fffffa800c300e10 0000000000000001 : Wdf01000!FxDevice::Dispatch+0x19a
> fffff8800d587890 fffff80002debf37 : fffffa800c485310 \> fffff8800d587b60
> fffffa800c485310 fffffa800d00c750 :
> Wdf01000!FxDevice::DispatchWithLock+0xa6
> fffff8800d5878d0 fffff80002dec796 : 0000000000000000 \> 0000000000000000
> 0000000000000000 0000000000000000 : nt!IopXxxControlFile+0x607
> fffff8800d587a00 fffff80002acce93 : fffffa800ceaf1a0 \> 0000007fffffffff
> fffff8800d587a88 0000098000000000 : nt!NtDeviceIoControlFile+0x56
> fffff8800d587a70 0000000076df138a : 0000000000000000 \> 0000000000000000
> 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
> 000000001153cf18 0000000000000000 : 0000000000000000 \> 0000000000000000
> 0000000000000000 0000000000000000 : 0x76df138a
>
>
> FOLLOWUP_IP:
> DriverName!doGetConfigInfo+bf3 [d:\path\ioctl.c @ 1913]
> fffff88008b1c533 f3aa rep stos byte ptr [rdi] \> \> SYMBOL_STACK_INDEX: 0 \> \> SYMBOL_NAME: DriverName!doGetConfigInfo+bf3 \> \> FOLLOWUP_NAME: MachineOwner \> \> MODULE_NAME: DriverName \> \> IMAGE_NAME: DriverName.sys \> \> DEBUG_FLR_IMAGE_TIMESTAMP: 51ea9b25 \> \> STACK_COMMAND: .cxr 0xfffff8800d586690 ; kb \> \> FAILURE_BUCKET_ID: X64_0x3B_DriverName!doGetConfigInfo+bf3 \> \> BUCKET_ID: X64_0x3B_DriverName!doGetConfigInfo+bf3 \> \> Followup: MachineOwner \> --------- \> \> 2: kd\> lmvm DriverName \> start end module name \> fffff88008b0c000 fffff880`08b22000 DriverName (private pdb symbols)
> p:\path\DriverName.pdb
> Loaded symbol image file: DriverName.sys
> Image path: \SystemRoot\System32\Drivers\DriverName.sys
> Image name: DriverName.sys
> Timestamp: Sat Jul 20 07:13:57 2013 (51EA9B25)
> CheckSum: 0001A107
> ImageSize: 00016000
> Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer