Hi,
I am trying my first Driver for USB. I take source code from ddk.…\wdm\usb\bulkusb as a reference. Everything goes fine until I copied routine IoAttachDeviceToDeviceStack to my AddDevice routine. When I added this routine, the system goes blue screen. Can anybody help me?
Here is my code for AddDevice:
NTSTATUS DrvAddDevice(IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT pdo)
{
PDEVICE_OBJECT pfdo;
PDEVICE_EXTENSION pdx;
…
ntStatus = IoCreateDevice(DriverObject,
sizeof(DEVICE_EXTENSION),
NULL, //&devName,
FILE_DEVICE_UNKNOWN,
FILE_AUTOGENERATED_DEVICE_NAME,
FALSE,
&pfdo);
…
pdx->TopOfStackDeviceObject = IoAttachDeviceToDeviceStack(pfdo,pdo);
}
The definition of DEVICE_EXTENSION are the same as ddk examples. How can this IoAttachDeviceToDeviceStack(pfdo,pdo) cause blue screen?
Try attaching a debugger and stepping through the code, making sure
that all variables have sensible values e.g. have you actually
assigned a proper value to pdx ? Find out exactly what is causing
the crash, most likely writing to invalid memory due to uninitialised
variables.
You’ll get ahead far quicker if you learn to rely on a debugger
rather than post questions here the moment you are stuck. The art of
programming is not really about writing code, its about knowing how
to find the problem with the code you’ve written and fix it. Using
the list for this type of thing is a very inefficient way of doing things.
At 09:26 07/05/2008, xxxxx@hotmail.com wrote:
Hi,
I am trying my first Driver for USB. I take source code from
ddk.…\wdm\usb\bulkusb as a reference. Everything goes fine until I
copied routine IoAttachDeviceToDeviceStack to my AddDevice routine.
When I added this routine, the system goes blue screen. Can anybody help me?
Here is my code for AddDevice:
NTSTATUS DrvAddDevice(IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT pdo)
{
PDEVICE_OBJECT pfdo;
PDEVICE_EXTENSION pdx;
…
ntStatus = IoCreateDevice(DriverObject,
sizeof(DEVICE_EXTENSION),
NULL, //&devName,
FILE_DEVICE_UNKNOWN,
FILE_AUTOGENERATED_DEVICE_NAME,
FALSE,
&pfdo);
…
pdx->TopOfStackDeviceObject = IoAttachDeviceToDeviceStack(pfdo,pdo);
}
xxxxx@muttsnuts.com wrote:
Try attaching a debugger and stepping through the code, making sure that all variables have sensible values e.g. have you actually assigned a proper value to pdx ? Find out exactly what is causing the crash, most likely writing to invalid memory due to uninitialised variables.
I only have one computer to debug my driver, so I can’t use windbg. What I have is debugview and I print messages to debugview to check if I got right result. Should I initialize StackSize before I use IoAttachDeviceToDeviceStack? Thanks very much.
At the risk of sounding condescending, you don’t have the right tools
to get the job done properly and your manager should be made aware of
this. If you’re not allowed a second machine to act as a debugger,
then you’re being setup to fail.
Having said that, why don’t you ensure that at least a kernel dump
file is written on BSOD. Then you can post analyse the dump file in Windbg.
!analyze -v is your very best friend.
Mark.
At 10:12 07/05/2008, xxxxx@hotmail.com wrote:
xxxxx@muttsnuts.com wrote:
>Try attaching a debugger and stepping through the code, making
sure that all variables have sensible values e.g. have you actually
assigned a proper value to pdx ? Find out exactly what is causing
the crash, most likely writing to invalid memory due to
uninitialised variables.
I only have one computer to debug my driver, so I can’t use windbg.
What I have is debugview and I print messages to debugview to check
if I got right result. Should I initialize StackSize before I use
IoAttachDeviceToDeviceStack? Thanks very much.
xxxxx@muttsnuts.com wrote:
Having said that, why don’t you ensure that at least a kernel dump file is written on BSOD. Then you can post analyse the dump file in Windbg.
Thank you very much. I will try that.
Then you need to get a second machine. If you intend to work in the kernel,
there is a cost, and one of those costs is that you need 2 machines. One for
development with WinDbg installed, and one that is the target where you have
enabled the debugger during boot and have connected to it via 1394. You
install your test driver on the target and then use WinDbg to step into your
code, as Mark suggested. You also use WinDbg to work with the driver
verifier which provides a wealth of diagnostic information during
development. You cannot use !analyze -v on DebugView, and that, in and of
itself, speaks to the futility of attempting to do single machine
development in the kernel.
Why are you not using WDF for development?
Of course since you currently are stumbling around blindly attempting to do
kernel development with only a single machine, I doubt it useless to also
mention that the target should have more than one processor.
–
The personal opinion of
Gary G. Little
wrote in message news:xxxxx@ntdev…
> xxxxx@muttsnuts.com wrote:
>
>>Try attaching a debugger and stepping through the code, making sure that
>>all variables have sensible values e.g. have you actually assigned a
>>proper value to pdx ? Find out exactly what is causing the crash, most
>>likely writing to invalid memory due to uninitialised variables.
>
> I only have one computer to debug my driver, so I can’t use windbg. What I
> have is debugview and I print messages to debugview to check if I got
> right result. Should I initialize StackSize before I use
> IoAttachDeviceToDeviceStack? Thanks very much.
>
In addition to what others said, you should really use WDF instead of
BulkUsb sample. It is bad and obsolete (search archives if you want to
know details). Even if you solve your current problem, you will
encounter more and more. With KMDF or UMDF you can write your driver
much faster and for UMDF driver you don’t even need the second
development machine.
Anyway, using WinDbg to analyse crashdumps is one of basic driver
development skills.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, May 07, 2008 10:27 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IoAttachDeviceToDeviceStack
Hi,
I am trying my first Driver for USB. I take source code from
ddk.…\wdm\usb\bulkusb as a reference. Everything goes fine
until I copied routine IoAttachDeviceToDeviceStack to my
AddDevice routine. When I added this routine, the system goes
blue screen. Can anybody help me?
Here is my code for AddDevice:
NTSTATUS DrvAddDevice(IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT pdo)
{
PDEVICE_OBJECT pfdo;
PDEVICE_EXTENSION pdx;
…
ntStatus = IoCreateDevice(DriverObject,
sizeof(DEVICE_EXTENSION),
NULL, //&devName,
FILE_DEVICE_UNKNOWN,
FILE_AUTOGENERATED_DEVICE_NAME,
FALSE,
&pfdo);
…
pdx->TopOfStackDeviceObject =
IoAttachDeviceToDeviceStack(pfdo,pdo);
}
The definition of DEVICE_EXTENSION are the same as ddk
examples. How can this IoAttachDeviceToDeviceStack(pfdo,pdo)
cause blue screen?
NTDEV is sponsored by OSR
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 only have one computer to debug my driver, so I can’t use windbg.
What happened to good old VMWare??? IIRC, WinDbg works just fine with it everywhere, including even Vista. If you write a driver that actually controls the target hardware (i.e. access BARs, do DMA, handle interrupts, etc), them, probably, VMWare is not the best idea. However, in vast majority of cases debugging with VMWare is not a bad option for someone who just cannot afford the second machine…
Anton Bassov
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, May 07, 2008 6:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IoAttachDeviceToDeviceStack
> I only have one computer to debug my driver, so I can’t use windbg.
What happened to good old VMWare??? IIRC, WinDbg works just
fine with it everywhere, including even Vista. If you write a
driver that actually controls the target hardware (i.e.
access BARs, do DMA, handle interrupts, etc), them, probably,
VMWare is not the best idea. However, in vast majority of
cases debugging with VMWare is not a bad option for someone
who just cannot afford the second machine…
In my experience it isn’t very good for USB drivers development (which
OP does). It is somewhat possible but VMware USB drivers at host
negatively influence timing and sometimes also data. I’ve encountered
cases when software running in VM received stale data which should be
gone after port or pipe reset or cleanup and so on. VMware is great for
software only drivers development (FS filters for example) but not for
real hardware.
BTW, isn’t the second low end machine sufficient for debugging cheaper
nowadays than a VMware license?
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> In my experience it isn’t very good for USB drivers development (which OP does).
Actually, I thought that it applies only to those devices that deal with controllers - indeed, VMWAre may have its “surprises” when you access BARs. However, as it turns out, it may have some other “surprises” as well…
BTW, isn’t the second low end machine sufficient for debugging cheaper nowadays
than a VMware license?
In fact, I don’t really know what you mean by “low end machine sufficient for debugging”, but I would not
buy anything below Core2 Duo for either development or debugging (i.e. CPU alone is almost twice more expensive than VMWare licence)…
Anton Bassov
Mark S. Edwards wrote:
Having said that, why don’t you ensure that at least a kernel dump file
is written on BSOD. Then you can post analyse the dump file in Windbg.
!analyze -v is your very best friend.
Crash dump debugging is so useful (and has become so easy) that recently
even a local PC Games Magazine (!) published a three-page article on how
to do crash dump debugging for Windows.
They used an example where a HD connector cable was not properly
inserted, and showed how the crash dump proved a way to corner the
problem’s source.
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, May 07, 2008 11:38 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IoAttachDeviceToDeviceStack
Actually, I thought that it applies only to those devices
that deal with controllers - indeed, VMWAre may have its
“surprises” when you access BARs. However, as it turns out,
it may have some other “surprises” as well…
VMware installs USB drivers at host side to be able to use devices
inside VM. So you have original OS drivers + VMware drivers + OS drivers
running inside VM. It has to behave a bit differently and it does.
Depends on the device and communication protocol, of course.
In fact, I don’t really know what you mean by “low end
machine sufficient for debugging”, but I would not
buy anything below Core2 Duo for either development or
debugging (i.e. CPU alone is almost twice more expensive than
VMWare licence)…
Anything which can run target OS and debugged driver. Driver has to be
tested at SMP machine but it doesn’t need to be the development one.
Anyway, I’m not experienced in this area. Instead of most members of
this list I believe a debugger is unnecessary and one machine is quite
sufficient for driver development. OTOH, I guess for most beginners two
machines and debugger is better choice.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Thursday, May 08, 2008 12:03 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IoAttachDeviceToDeviceStack
Crash dump debugging is so useful (and has become so easy)
Yes. This week I taught our QA member how to do it within few minutes.
Previously I asked her to report me any BSOD they encounter but it was
tiresome to analyze all these ATI drivers crashes. Now she can quickly
decide herself if it is worthwhile to create a report.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> Instead of most members of this list I believe a debugger is unnecessary
Well, I just don’t know what to say to that. To be honest, I had almost never used a kernel debugger for the actual purpose of debugging - my main use of kernel debugger was disassembling the system.
In my experience, the only thing debugger allows is catching the most stupid mistakes that are obvious on the very first run (passing the wrong parameter to a function, accessing invalid pointer, etc). When it comes to not-so-obvious random bugs like deadlocks, random crashes because of memory corruption, etc, debugger is of little help - in my experience, the most efficient approach to take here is just to go through a thorough review of your code. Crash dump analysis is your friend here, because it shows you the call stack so that you know which particular function causes trouble. Quite often, after taking just a brief look at your code you say “What the fuck was I thinking with when I typed this stupid code…”
Anton Bassov
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, May 08, 2008 2:07 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IoAttachDeviceToDeviceStack
Well, I just don’t know what to say to that.
Maybe you could try something new and don’t say anything 
Well, it is one of my favorite topics but I don’t want to hijack this
thread. Every mail so far was somewhat related to the original question
but this isn’t. OP clearly needs to learn standard ways how to debug
drivers and such a discussion would only make confusion. So I’m sorry
but I won’t discuss it here.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
wrote in message news:xxxxx@ntdev…
>> Instead of most members of this list I believe a debugger is unnecessary
>
> Well, I just don’t know what to say to that. To be honest, I had almost
> never used a kernel debugger for the actual purpose of debugging - my main
> use of kernel debugger was disassembling the system.
So rather than playing, like Paganini, on just one chord,
you’re like Papa Karlo with a jigsaw studying how a violin works 
> In my experience, the only thing debugger allows is catching the most
> stupid mistakes that are obvious on the very first run (passing the wrong
> parameter to a function, accessing invalid pointer, etc). When it comes to
> not-so-obvious random bugs like deadlocks, random crashes because of
> memory corruption, etc, debugger is of little help - in my experience, the
> most efficient approach to take here is just to go through a thorough
> review of your code. Crash dump analysis is your friend here, because it
> shows you the call stack so that you know which particular function causes
> trouble. Quite often, after taking just a brief look at your code you say
> “What the fuck was I thinking with when I typed this stupid code…”
>
Another rare but interesting case when a debugger is not very useful - all
kinds of havoc
caused by runaway DMA or hardware/firmware bugs. It strikes asynchronously
so all you
get is a dump - not even call stack.
Regards,
–PA
> So rather than playing, like Paganini, on just one chord, you’re like
Papa Karlo with a jigsaw studying how a violin works
Well, unless you believe that debugging is not a skill but just an art that requires in-born talent (you must have a delusion of grandeur then), I really have no clue how Paganini may be possibly related to this discussion. I would rather prefer to associate myself with Papa Karlo example - after all, he is just one of us, “lowly techies”. If OS disassembly is “Papa Karlo studying how a violin works”, then debugging is “Papa Karlo trying to understand why a violin stopped working after the latest amendment that he made to it”, and the main tool that he uses is, in both cases, the same…
Another rare but interesting case when a debugger is not very useful - all kinds of havoc
caused by runaway DMA or hardware/firmware bugs. It strikes asynchronously so all you get is a
dump - not even call stack.
Well, in this particular case Papa Karlo’s task is relatively easy. If your target device does DMA and you crash for the reason that looks like memory corruption (in this case you are more than likely to see anyone but your driver named as a culprit on a BSOD, because you may just corrupt someone else’s memory), this is a good indication that you should just review the part that is responsible for DMA.
Unfortunately, memory corruption may be achieved in much more subtle ways. One of the most efficient ones that I know of is confusing an array and pointer. Some structures( for example, UNICODE_STRING) have a buffer declared as a pointer, but some have it as an array of DATATYPE[1]. There is no problem with allocating the former type on the stack, but consider what happens when you do the same thing with the latter one, and then pass this structure to some function that fills the array with data. If you are really lucky your driver will crash and burn because of overwritten return address so that you can catch it even with a debugger, but there is no guarantee you are going to be that lucky…
Anton Bassov
You might want to try assigning a value to pdx before actually using it.
On Wed, May 7, 2008 at 4:26 AM, wrote:
> Hi,
>
> I am trying my first Driver for USB. I take source code from
> ddk.…\wdm\usb\bulkusb as a reference. Everything goes fine until I copied
> routine IoAttachDeviceToDeviceStack to my AddDevice routine. When I added
> this routine, the system goes blue screen. Can anybody help me?
>
> Here is my code for AddDevice:
>
> NTSTATUS DrvAddDevice(IN PDRIVER_OBJECT DriverObject,
> IN PDEVICE_OBJECT pdo)
> {
>
> PDEVICE_OBJECT pfdo;
> PDEVICE_EXTENSION pdx;
>
> …
>
> ntStatus = IoCreateDevice(DriverObject,
> sizeof(DEVICE_EXTENSION),
> NULL, //&devName,
> FILE_DEVICE_UNKNOWN,
> FILE_AUTOGENERATED_DEVICE_NAME,
> FALSE,
> &pfdo);
>
> …
>
> pdx->TopOfStackDeviceObject =
> IoAttachDeviceToDeviceStack(pfdo,pdo);
>
> }
>
> The definition of DEVICE_EXTENSION are the same as ddk examples. How can
> this IoAttachDeviceToDeviceStack(pfdo,pdo) cause blue screen?
>
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
–
Mark Roddy
> Well, it is one of my favorite topics but I don’t want to hijack this thread.
Well, this is the very last thing you have to worry about - it has been successfully hijacked right in the very first reply by mentioning a debugger…
Every mail so far was somewhat related to the original question but this isn’t.
Really??? The original question was answered right in the very first reply - as Mark pointed out, the OP just uses uninitialized variable, i.e.the line pdx->TopOfStackDeviceObject =whatever_the_operand_is is just bound to cause a crash, so that all subsequent posts (including yours and mine) on this thread were already off-topic ones… Therefore, I think you can proceed to your favorite topic without having to worry about being accused of thread hijacking…
Anton Bassov
Thanks for all of your discussions. That gives different point to see the question. I will think of it seriously.