increase speed of DevPathExer tests when WinDbg is attached

NTDEV
1

Hi,

to figure out the reason for a BSOD during the DevPathExer test, I added several DbgPrints to our code. Then I attached the WinDbg. In the WinDbg I stored all info with .logopen d:\my.log in a log file. Now I started with:
DevPathExer /lwa /HCT /dr OurDirver
the DevPathExer test.

The DevPathExer needs 40 minutes to produce a BSOD.

When I do not attache the WinDbg (but still use the exactly same sys file, which still contains the DbgPrints) the DevPathExer test will produce the SAME BSOD in JUST ONE MINUTE!

================================================
After adding / modifying DbgPrints in the Code I don’t want always wait 40 minutes to get the new BSDO and the new log file (that I produce with the above described way).

Therefore I tried several things:

With the DevPathExer options /c and /r I tried to produce the crashn.log & crash.log. I read here:
http://msdn.microsoft.com/en-us/library/ff544854.aspx
that you can use the /r option to execute just on sub test of DevPathExer. But it didn’t worked properer.
They say you can delete the test, which you want to perform from the crashn.log. The option /r should skip all the test in crashn.log. But the test removed from crashn.log should be perfromed. I tried this way, without success.

When I perform
DevPathExer /lwa /HCT /dr OurDirver
without attached WinDbg one of the last thing in the command line box, that I read was something like IOCTL/ FSCTL. Therefore tried:
DevPathExer /fn and DevPathExer /in
==> my hope was to get the same BSOD with only performing this " Zero-Length Buffer Test " . But with this options I did not got the BSOD in just one minute. Since those both options also lead to long tests without the desired BSOD I stopped this tests. Even with detached WinDbg these options lead to tests longer than a minute.

=================================

Since one of the last thing that I always read before the BSOD is IOCTL/ FSCTL. I think that my BSDO is produces bye a " Zero-Length Buffer Test ".

===> What must I do, to get a BSDO after JUST ONE MINUTE, EVEN WHEN THE WINDBG IS ATTACHED ???

Thanks in advance for all your helpful hints.

2

xxxxx@siemens.com wrote:

to figure out the reason for a BSOD during the DevPathExer test, I added several DbgPrints to our code. Then I attached the WinDbg. In the WinDbg I stored all info with .logopen d:\my.log in a log file. Now I started with:
DevPathExer /lwa /HCT /dr OurDirver
the DevPathExer test.

The DevPathExer needs 40 minutes to produce a BSOD.

When I do not attache the WinDbg (but still use the exactly same sys file, which still contains the DbgPrints) the DevPathExer test will produce the SAME BSOD in JUST ONE MINUTE!

Are you doing a LOT of DbgPrints? Remember that Windbg is a huge
bottleneck. When you do a DbgPrint, the system essentially comes to a
grinding halt while the kernel debug hook transmits your string to the
remote system. If you are using a serial port, that is a painfully slow
process. Sending an 80 character string over a 19200 baud link takes 50
milliseconds. That’s an incredibly long time, in computer terms, and
your machine can’t do anything else until it is sent.

ARE you using a serial port? The situation is much better over 1394.

After adding / modifying DbgPrints in the Code I don’t want always wait 40 minutes to get the new BSDO and the new log file (that I produce with the above described way).

How impatient we have all become. It wasn’t that long ago that
debugging even a simple program meant submitting a card deck and waiting
4 hours to pick up a printout. One got very good at desk-checking in
that environment.

You could think of it as a chance to meditate, or to catch up on your
other tasks. :wink:

===> What must I do, to get a BSDO after JUST ONE MINUTE, EVEN WHEN THE WINDBG IS ATTACHED ???

If you know that the error occurs after 10,000 iterations of something,
you could always put a counter in your code, and suppress all of the
DbgPrints until the counter reaches 10,000.

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

3

Not at all surprised that it took forever to get to the same point in your
failure, debug prints are slow. The best case is a single CPU target, over
firewire. The worst case is a multi-CPU target over serial port. Multi-CPU
debug printing is slow, even over firewire, because the OS corrals all the
CPUs before dumping the string to the output buffer. Basically, a debug
print is like a breakpoint, except it continues executing after dumping to
the buffer. There was a lot of chatter about that a few years ago on the
windbg list, I don’t know if Vista/Win7 has improved this issue at all.

Since you have the run with the debugger attached, if you run without the
debug prints, you can get back to reproducing the BSOD in a minute or so,
and the offending code might be at top of the stack at the point of the
BSOD. Disable your debug prints, run to the crash, then paste the output
from !analyze -v here. If it says you have a problem with your symbols, fix
your symbols and run !analyze -v again, and paste that output. Don’t bother
pasting anything with broken symbols, there’s rarely anything useful in
that.

Phil

Philip D. Barila??? (303) 776-1264

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@siemens.com
Sent: Tuesday, March 08, 2011 10:24 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] increase speed of DevPathExer tests when WinDbg is attached

Hi,

to figure out the reason for a BSOD during the DevPathExer test, I added
several DbgPrints to our code. Then I attached the WinDbg. In the WinDbg I
stored all info with .logopen d:\my.log in a log file. Now I started with:
DevPathExer /lwa /HCT /dr OurDirver
the DevPathExer test.

The DevPathExer needs 40 minutes to produce a BSOD.

When I do not attache the WinDbg (but still use the exactly same sys file,
which still contains the DbgPrints) the DevPathExer test will produce the
SAME BSOD in JUST ONE MINUTE!

================================================
After adding / modifying DbgPrints in the Code I don’t want always wait 40
minutes to get the new BSDO and the new log file (that I produce with the
above described way).

Therefore I tried several things:

With the DevPathExer options /c and /r I tried to produce the crashn.log &
crash.log. I read here:
http://msdn.microsoft.com/en-us/library/ff544854.aspx
that you can use the /r option to execute just on sub test of DevPathExer.
But it didn’t worked properer.
They say you can delete the test, which you want to perform from the
crashn.log. The option /r should skip all the test in crashn.log. But the
test removed from crashn.log should be perfromed. I tried this way, without
success.

When I perform
DevPathExer /lwa /HCT /dr OurDirver
without attached WinDbg one of the last thing in the command line box, that
I read was something like IOCTL/ FSCTL. Therefore tried:
DevPathExer /fn and DevPathExer /in
==> my hope was to get the same BSOD with only performing this " Zero-Length
Buffer Test " . But with this options I did not got the BSOD in just one
minute. Since those both options also lead to long tests without the desired
BSOD I stopped this tests. Even with detached WinDbg these options lead to
tests longer than a minute.

=================================

Since one of the last thing that I always read before the BSOD is IOCTL/
FSCTL. I think that my BSDO is produces bye a " Zero-Length Buffer Test ".

===> What must I do, to get a BSDO after JUST ONE MINUTE, EVEN WHEN THE
WINDBG IS ATTACHED ???

Thanks in advance for all your helpful hints.

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

4

Assuming that you can do your debugging in a VM (VMWare Workstation or
VirtualBox specifically), you might also want to consider using VirtualKD,
because it TOTALLY RAWKS.

http://virtualkd.sysprogs.org/

The combination of speed + snapshots is by far the option out there at the
moment, in my opinion, provided you don’t need real hardware, of course.

Good luck,

mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, March 08, 2011 12:32 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] increase speed of DevPathExer tests when WinDbg is
attached

xxxxx@siemens.com wrote:

to figure out the reason for a BSOD during the DevPathExer test, I added
several DbgPrints to our code. Then I attached the WinDbg. In the WinDbg I
stored all info with .logopen d:\my.log in a log file. Now I started with:
DevPathExer /lwa /HCT /dr OurDirver
the DevPathExer test.

The DevPathExer needs 40 minutes to produce a BSOD.

When I do not attache the WinDbg (but still use the exactly same sys file,
which still contains the DbgPrints) the DevPathExer test will produce the
SAME BSOD in JUST ONE MINUTE!

Are you doing a LOT of DbgPrints? Remember that Windbg is a huge
bottleneck. When you do a DbgPrint, the system essentially comes to a
grinding halt while the kernel debug hook transmits your string to the
remote system. If you are using a serial port, that is a painfully slow
process. Sending an 80 character string over a 19200 baud link takes 50
milliseconds. That’s an incredibly long time, in computer terms, and
your machine can’t do anything else until it is sent.

ARE you using a serial port? The situation is much better over 1394.

After adding / modifying DbgPrints in the Code I don’t want always wait 40
minutes to get the new BSDO and the new log file (that I produce with the
above described way).

How impatient we have all become. It wasn’t that long ago that
debugging even a simple program meant submitting a card deck and waiting
4 hours to pick up a printout. One got very good at desk-checking in
that environment.

You could think of it as a chance to meditate, or to catch up on your
other tasks. :wink:

===> What must I do, to get a BSDO after JUST ONE MINUTE, EVEN WHEN THE
WINDBG IS ATTACHED ???

If you know that the error occurs after 10,000 iterations of something,
you could always put a counter in your code, and suppress all of the
DbgPrints until the counter reaches 10,000.

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

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

5

Ok thanks so far, for that fast & good answers.

  1. Unfortunately this machine does not have a 1394 port and also no free slot for a 1394 card.

  2. The VM idea also sounds good. But I am not sure, whether I can do this on this weak / slow computer.

  3. Wouldn’t it be the best solution: to force the DevPathExer just to execute the sub-test, which
    causes the BSDO ???

  4. Does somebody know how to do this ???

(I guess that the BSDO is caused thru a “” Zero-Length Buffer Test "; but I am not sure )

6

xxxxx@siemens.com wrote:

  1. Wouldn’t it be the best solution: to force the DevPathExer just to execute the sub-test, which
    causes the BSDO ???

I’m not trying to be flippant here, but if you can’t reduce the DbgPrint
traffic, the best solution is probably to be patient and wait 40 minutes
for each result. If you target your DbgPrints carefully, it shouldn’t
take very many runs to isolate the issue. And since you will be in
Windbg, you have the benefit of being able to poke around in live memory
to get additional forensic data.

In a sense, you are somewhat fortunate here. Wait until you start
running the standby/sleep/hibernate/resume tests. Those take 8 or 10
HOURS to run. When you make a stupid mistake that causes a hibernate
resume crash on the 83rd iteration, you really start cursing the gods of
computing.

(I guess that the BSDO is caused thru a “” Zero-Length Buffer Test "; but I am not sure )

You might post the !analyze -v results. Perhaps someone here will
recognize it.

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

7

Tim,

Try doing the storage adapter tests on something like ISCSI, they can
easily take 72 hours or more. This has always been a WHQL failing, that
they do not give you enough information to run the tests standalone and
in a way to optimize what you want to test.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Tim Roberts” wrote in message news:xxxxx@ntdev:

> xxxxx@siemens.com wrote:
> > 1. Wouldn’t it be the best solution: to force the DevPathExer just to execute the sub-test, which
> > causes the BSDO ???
>
> I’m not trying to be flippant here, but if you can’t reduce the DbgPrint
> traffic, the best solution is probably to be patient and wait 40 minutes
> for each result. If you target your DbgPrints carefully, it shouldn’t
> take very many runs to isolate the issue. And since you will be in
> Windbg, you have the benefit of being able to poke around in live memory
> to get additional forensic data.
>
> In a sense, you are somewhat fortunate here. Wait until you start
> running the standby/sleep/hibernate/resume tests. Those take 8 or 10
> HOURS to run. When you make a stupid mistake that causes a hibernate
> resume crash on the 83rd iteration, you really start cursing the gods of
> computing.
>
> > (I guess that the BSDO is caused thru a “” Zero-Length Buffer Test "; but I am not sure )
>
> You might post the !analyze -v results. Perhaps someone here will
> recognize it.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.