RamDisk on Windows7

NTDEV
21

I agree with that…

Sorry, but (a) I didn’t retract this statement, and (b) I stand by it.

Print/Trace is ONE type of debugging in one’s arsenal. Using the debugger provides a whole lot more. For MOST driver models, I do not think it is practical to use DebugView to debug your driver effectively.

Using DebugView to debug your driver limits you to one approach, requires a constant modification of your print/trace statements to deal with the situation at hand, and requires you to re-invent the wheel.

Without the debugger, you don’t have the KMDF debugger extensions. How do you read the IFR (!WDFLOGDUMP)? View the hierarchy of objects? The state of and in-progress requests on each queue??

With the debugger, how do you show the state of the ERESOURCE locks (!LOCKS) your driver holds, or how much they are contended?

How do you find all the IRPs allocated in the system?

In summary: I’ll grant that print/trace works. I’ll grant that there are people, with excellent abilities and reputations such as yourself, who are successful with using this approach alone.

What I won’t agree is that ANY dev – new or old – should voluntarily restrict their options to ONLY ever using print/trace, when there are other very useful tools available. If you’re doing an NDIS driver, a KMDF driver, and many others… the debugger is THE way to tap into system information (collected via traces and other means) that will help you diagnose large, complex, interaction problems.

Print/Trace is ONE tool… The debugger is the key to a whole range of OTHER tools. The ability to debug complex problems requires an engineer have the ability to understand and employ “the best tool for the job.”

To the OP’s problem: If the OP had been able to use a debugger, he probably wouldn’t have had to post on this list. He would have gotten a crash dump, done !analyze -v, looked at the structures in his driver, and figured out his problem!

If that didn’t help… sure, he could add tracing. But that would be iterative: Add IRP enter/exit tracing at each dispatch/event processing entry point. Run the test… OK, that tells us there’s a problem in an IOCTL. Let’s see the arguments: Edit the source, add more tracing to print the IOCTL control code. Run the test again. OK, it’s the IOCTL_DISK_SOMETHING function. It takes 2 arguments, one of which points to a structure. Fine. Edit the source, and add more tracing that prints out the arguments, and the contents of the structure. Run the test again.

Sorry, THAT seems difficult and doesn’t make a great deal of sense to me.

Alternative using the debugger: Set a breakpoint at each dispatch entry point. Observe crash. Rerun test. Stop before problematic IOCTL, step into code. Problem solved.

That just seems like a better, quicker, easier option to me…

Peter
OSR

22

Alas, in the this world, the employe good by this definition, too often is
no longer an employee.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> shohug hasan wrote:
>> I am creating ramdisk as it is my job
>>
>
> This is not a good enough reason. Allow me to explain.
>
> The fundamental requirement is that your management wants a ramdisk.
> One possible path to satisfy that requirement is to write one. Another
> possible path is to acquire one. For this particular task, it is
> utterly foolish for you to go about writing Yet Another Ramdisk, when
> the problem has been adequately solved many, many, many times before.
> It would be FAR less expensive for your company to buy a working ramdisk
> than it will be for you to write one from scratch, work through all of
> the same painful debugging issues that many others have worked through
> before you, and still end up with a product that has not had the level
> of testing that existing products have.
>
> It is NOT a good return on investment. A good employee is always
> willing to point out when his management has embarked on an incorrect
> course of action. A good employee will not blindly follow a course of
> action when there are better alternatives.
>
>> Hi, i am developing RamDisk Driver The RamDisk works fine but when i try
>> to format Ram Drive by right clicking on it then the explorer crushes
>> with “shell32.dll error”.
>
> I’m seeing this word misused more and more, and I’d like to correct it
> now, so that others that follow can get the proper term. The word is
> not “crushes”. The proper word is “crashes”.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

23

> And then Anton would feel duty bound to reply reply and say something like "No, Linus Tovalds

is most certainly NOT a dickless ass-hat, despite what Peter says." And then… Well, you know.
It would degenerate from there.

Interesting approach - you make a provocative post which you know may possibly result in a flame war,
and somehow expect to shift the responsibility for hijacked thread to me, despite the fact that I am not even participating in it …

In any case, this particular thread seems to have qualified for being moved to NTTALK long before
Linus was mentioned on it …

Anton Bassov

24

Well… yeaaaahh. Who else would I blame?

You don’t think I’M going to take responsibility for my own irresponsible behavior, do you?

You ARE right, though. This belongs on NTTALK. Wonder if I can “move” a thread??

[Later: Sadly, the answer is “NO”… it’s really not practical to “move” threads on this server, as each list has a separate membership.]

Peter
OSR

25

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@osr.com
Sent: Friday, July 17, 2009 10:58 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RamDisk on Windows7

Using DebugView to debug your driver limits you to one
approach, requires a constant modification of your
print/trace statements to deal with the situation at hand,

This indicates insufficient traces. I very rarely have a need to add new
traces to debug a problem. Just use existing ones which I added during
coding phase. That’s why I say traces have to be integral part of the
code. If you’re using them as the second level tool as you indicate
above, they lose most of their value.

The value is efficiency. There is a problem -> ask QA/customer to
configure trace levels accordingly -> reproduce problem -> send me the
log -> I examine the log -> find the problem. No code change. I can
solve most problems this way within few minutes which is less time than
I’d find the machine where it was reproduced (if it is in our building).

and requires you to re-invent the wheel.

Which wheel?

Without the debugger, you don’t have the KMDF debugger
extensions. How do you read the IFR (!WDFLOGDUMP)? View the
hierarchy of objects? The state of and in-progress requests
on each queue??

With the debugger, how do you show the state of the ERESOURCE
locks (!LOCKS) your driver holds, or how much they are contended?

How do you find all the IRPs allocated in the system?

If I need something like this, I create a crash dump and make analysis.
I already said WinDbg is great crashdump analysis tool. But above is not
typical debugger use, it is post mortem analysis even if you do it at
live system (stopped in this moment). I prefer crash dump approach
because saves me from all the nonsense with connecting the debugger and
can be done by somebody else. A hotkey or your Bang! tool are enough.
Also, in most cases when it is necessary OS already crashed on its own.

In other words, it is perfectly valid and helpful approach but not
debugger use we were talking about (single stepping, breakpoints).

Print/Trace is ONE tool… The debugger is the key to a whole
range of OTHER tools. The ability to debug complex problems
requires an engineer have the ability to understand and
employ “the best tool for the job.”

Yes, I agree. I just say typical debugger tools i.e. single stepping and
breakpoints aren’t (shouldn’t be) essential tools for experienced
developers. Need an analysis at some well defined point? Failing assert
should be already there invoking a bugcheck.

To the OP’s problem: If the OP had been able to use a
debugger, he probably wouldn’t have had to post on this list.
He would have gotten a crash dump, done !analyze -v, looked
at the structures in his driver, and figured out his problem!

If I understood correctly, it was shell32.dll what crashed (i.e.
probably exploder), not whole OS. From user mode crashdump it would be
hard to find real cause. I’d bet it was some IRP completed by his driver
just before crash and from traces it’d be immediatelly visible.

If that didn’t help… sure, he could add tracing. But that
would be iterative: Add IRP enter/exit tracing at each
dispatch/event processing entry point. Run the test… OK,
that tells us there’s a problem in an IOCTL. Let’s see the
arguments: Edit the source, add more tracing to print the
IOCTL control code. Run the test again. OK, it’s the
IOCTL_DISK_SOMETHING function. It takes 2 arguments, one of
which points to a structure. Fine. Edit the source, and add
more tracing that prints out the arguments, and the contents
of the structure. Run the test again.

That’s completely wrong. Everything should be already there. Maybe it
was when OP mentioned his debug statements look good.

Sorry, THAT seems difficult and doesn’t make a great deal of
sense to me.

This way it is difficult, of course. But it isn’t the efficient way, it
is the way how to NOT use traces. That’s my main complaint against
debuggers. If they aren’t available, (reasonable) people would write
traces to the code in coding phase and don’t need to do (almost) any
change when debugging a problem. Used to the debugger they add traces as
you indicate to solve particular problems only. In turn, it is less
efficient than stepping through code.

Alternative using the debugger: Set a breakpoint at each
dispatch entry point. Observe crash. Rerun test. Stop
before problematic IOCTL, step into code. Problem solved.

That just seems like a better, quicker, easier option to me…

With correct traces: change few values in the registry to set necessary
debug levels. Rerun the test. Examine the log. Problem solved.

Now just imagine the problem you need to debug is on the machine on the
other side of the World (usual in our case with Chinese and Japanese
customers). Where are you with the debugger? With traces I work the same
way.

BTW, just for matter of interest: my current UMDF driver containing a
big user mode library written by two teams of people contains almost
6000 traces and 2500 asserts (counted using BSC references). I never ran
it under a debugger.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

26

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@osr.com
Sent: Friday, July 17, 2009 11:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RamDisk on Windows7

You don’t think I’M going to take responsibility for my own
irresponsible behavior, do you?

The strange thing is I feel the same (irresponsible) from the beginning.
And ironical thing is this was the only thread I read after returning
from holiday. Oh well. Move it if you can :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

27

Well, for ME it’s the most interesting thing on the list right now.

It’s summer, people are taking it easy… the questions haven’t been that very difficult.

Sadly, I *can’t* move threads on this server: Each list maintains its OWN group of members – so you can be a member of NTDEV and not of NTTALK (as you know). That results in the IDs of the people posting getting all screwed-up. Not to mention this weird, special, set of sequence numbers that the list server has to maintain to keep certain news readers happy (which apparently don’t like gaps in message numbers).

Peter
OSR

28

Thanks Peter – my monitor is now covered with coffee.

29

>Well, for ME it’s the most interesting thing on the list right now.

+1

It’s pretty much the only vaguely interesting thing I’ve seen in days, such as it is.

Alas

mm

30

Do you want to say I don’t need to read the rest of messages from the
last week? Great :slight_smile:

I’d like to know if it at least makes some of readers to think about
ways of their debugging. This or that way. Not you, who already know :slight_smile:

Now back to work…

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@evitechnology.com
Sent: Saturday, July 18, 2009 12:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RamDisk on Windows7

>Well, for ME it’s the most interesting thing on the list right now.

+1

It’s pretty much the only vaguely interesting thing I’ve seen
in days, such as it is.

Alas

mm

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

31

Michal,

Yes, this discussion has made me think again about debugging techniques and
also about past experiences and company policies with regards to debug/trace
statements in release code (which I will refrain to going into here).

I am sure there are lots of lurkers like myself who are able to gather a
number of useful nuggets from these discussions, as well as being challenged
to consider different ideas/techniques/etc…

Regards,
Kosta

On Fri, Jul 17, 2009 at 3:24 PM, Michal Vodicka wrote:

> Do you want to say I don’t need to read the rest of messages from the
> last week? Great :slight_smile:
>
> I’d like to know if it at least makes some of readers to think about
> ways of their debugging. This or that way. Not you, who already know :slight_smile:
>
> Now back to work…
>
> 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@evitechnology.com
> > Sent: Saturday, July 18, 2009 12:11 AM
> > To: Windows System Software Devs Interest List
> > Subject: RE:[ntdev] RamDisk on Windows7
> >
> > >Well, for ME it’s the most interesting thing on the list right now.
> >
> > +1
> >
> > It’s pretty much the only vaguely interesting thing I’ve seen
> > in days, such as it is.
> >
> > Alas
> >
> > mm
> >
> > —
> > 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
> >
>
> —
> 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
>

32

I agree this, 100% – Yes, absolutely. Tracing for a product IN THE FIELD is invaluable.

So we agree there.

But… wait: Your complaint really ISN’T with DEBUGGERS, per say. It’s with people who don’t have the proper engineering discipline or procedure to add tracing to their code for debugging in the field. OK!

So, right. I agree: People should put tracing in their code. We can set that aside now. We both agree. We have from the beginning.

OK… so, the debugger itself is not intrinsically evil in your mind. It has its place. In fact, for some things you agree it’s a “great… tool.”

So we agree there.

So, you don’t REALLY think that devs shouldn’t learn to use a debugger or make believe it doesn’t exist or not use it. Because, as you said, it’s a good "analysis tool “even if you do it at live system.”

THUS, apparently we disagree about is whether breakpoints and single stepping is useful.

Yes?

Hmmmm… I’d still like to know how you get the KMDF trace log out of your driver… so it can tell you WHY your call to WdfBlahWithBlah returned STATUS_INVALID_SOMETHING_STUPID. Of course, you would have traced out that you got this status, but… HOW do you now consult the IFR? If it were me, I’d set a breakpoint on that trace statement:

if (!NT_SUCESS(returnCode) ) {

traceSomeStuff(returnCode);

}

and do a !WDFLOGDUMP. But, that’s just me.

Never mind…

AND, we apparently disagree as to the correctness of the following statement:

You really can not use DebugView to debug your driver effectively.

Which I still stand by. If “effective” means “you don’t a priori know everything that’s going to happen in your driver and therefore you can’t trace out every single parameter to every single function.”

OK. That is now a very narrow area of disagreement. Narrow enough, I’d say, that we can just say that reasonable engineers will differ.

Peter
OSR

33

And Sherri? That’s probably the most USEFUL thing I’ve done all week. I feel all warm and fuzzy now.

Unless you count writing a module on how you do DMA in Windows drivers to be more useful. Reasonable engineers will differ on this…

Peter
OSR

34

Thanks, Kosta.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com http:</http:>]

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Kosta Koeman
Sent: Saturday, July 18, 2009 12:31 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] RamDisk on Windows7

Michal,

Yes, this discussion has made me think again about debugging
techniques and also about past experiences and company policies with
regards to debug/trace statements in release code (which I will refrain
to going into here).

I am sure there are lots of lurkers like myself who are able to
gather a number of useful nuggets from these discussions, as well as
being challenged to consider different ideas/techniques/etc…

Regards,
Kosta

On Fri, Jul 17, 2009 at 3:24 PM, Michal Vodicka
wrote:

Do you want to say I don’t need to read the rest of
messages from the
last week? Great :slight_smile:

I’d like to know if it at least makes some of readers to
think about
ways of their debugging. This or that way. Not you, who
already know :slight_smile:

Now back to work…

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com
http:</http:>]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf
Of
> xxxxx@evitechnology.com
> Sent: Saturday, July 18, 2009 12:11 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] RamDisk on Windows7
>
> >Well, for ME it’s the most interesting thing on the
list right now.
>
> +1
>
> It’s pretty much the only vaguely interesting thing
I’ve seen
> in days, such as it is.
>
> Alas
>
> mm
>
> —
> 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
>

—
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

— 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

35

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@osr.com
Sent: Saturday, July 18, 2009 12:32 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RamDisk on Windows7

But… wait: Your complaint really ISN’T with DEBUGGERS, per
say. It’s with people who don’t have the proper engineering
discipline or procedure to add tracing to their code for
debugging in the field. OK!

Basically, yes. However, some tools discourage using proper enginnering
procedures. Traces need some initial effort which may not seem necessary
when one can use single stepping. In our company it took years until
everybody started using traces properly. Most devs needed to see how
helpful it can be and once everybody was already convinced, we made it
mandatory.

THUS, apparently we disagree about is whether breakpoints and
single stepping is useful.

Yes?

Yes :slight_smile:

Hmmmm… I’d still like to know how you get the KMDF trace
log out of your driver… so it can tell you WHY your call to
WdfBlahWithBlah returned STATUS_INVALID_SOMETHING_STUPID. Of
course, you would have traced out that you got this status,
but… HOW do you now consult the IFR? If it were me, I’d
set a breakpoint on that trace statement:

if (!NT_SUCESS(returnCode) ) {

traceSomeStuff(returnCode);

}

and do a !WDFLOGDUMP. But, that’s just me.

Honestly, I never needed it, yet. I’d probably invoke a crashdump there
and run commands over it. I’d agree it can be less efficient if it
occurs often. But the main reason is we can’t easily turn on framework
traces and see them in DebugView (or can we?).

AND, we apparently disagree as to the correctness of the
following statement:

> You really can not use DebugView to debug your driver effectively.

Which I still stand by. If “effective” means “you don’t a
priori know everything that’s going to happen in your driver
and therefore you can’t trace out every single parameter to
every single function.”

You can and you should :slight_smile: This is our internal rule. Every function with
all parameters and return values have to be traced. I’m lazy so I wrote
macros for my editor which generate these traces from function header.

OK. That is now a very narrow area of disagreement. Narrow
enough, I’d say, that we can just say that reasonable
engineers will differ.

I’m fine with it. Once you’re bored with the driver development, you can
think about diplomatic career :wink:

Thanks for the discussion and have a nice weekend.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

36

>

Using DebugView to debug your driver limits you to one approach,
requires a
constant modification of your print/trace statements to deal with the
situation at hand, and requires you to re-invent the wheel.

If you are using only DebugView then you are selling yourself short.
But for some things it is much better than a debugger, particularly if
you are on the other side of the world to the machine you are debugging.

In a few cases a situation has arisen where a crash was occurring for
others but not me. By putting in a few strategic KdPrint’s I was able to
track down the problem much faster than I could have by remotely
debugging, or shipping a memory.dmp file across some fairly slow links.
(DebugView can extract KdPrint logs from a local memory.dmp file). The
problem as it turned out was something I couldn’t have reproduced with
the hardware I had available to me locally, and may not have even
occurred under the debugger due to timing differences (heisenbug).

These days under Xen I have the best of both worlds - windbg can connect
via a virtual serial port when required, and all KdPrints are captured
by Xen and logged to a file on the Linux side of things. Adding a few
KdPrints, rebuilding, uploading the drivers to the target machine, and
rebooting takes about 30 seconds. A boot with the debugger attached
takes upwards of 5 minutes (I’m normally at home when doing this,
connecting to machines over a 512/128kbps link). Guess which one I do
most?

There are of course problems that are best solved with an actual
debugger. It’s all about choosing the right tool for the job.

James

37

>

> And then Anton would feel duty bound to reply reply and say
something like
“No, Linus Tovalds
> is most certainly NOT a dickless ass-hat, despite what Peter says.”
And
then… Well, you know.
> It would degenerate from there.

Interesting approach - you make a provocative post which you know may
possibly
result in a flame war,
and somehow expect to shift the responsibility for hijacked thread to
me,
despite the fact that I am not even participating in it …

In any case, this particular thread seems to have qualified for being
moved
to NTTALK long before
Linus was mentioned on it …

I disagree. This particular element of the thread may qualify, but there
is some very wise advice from some very knowledgable people concerning
debugging which I think definitely belongs on ntdev.

James

38

Oh, yes. Certainly. That’s me all over: Mr. Diplomat.

You too. Definitely fun discussion.

Peter
OSR

39

James Harper wrote:

These days under Xen I have the best of both worlds - windbg can connect
via a virtual serial port when required, and all KdPrints are captured
by Xen and logged to a file on the Linux side of things.

I’ve been dubious of this technique in the past, mostly because I work
with physical devices that have not been virtualizable.

However, I think I posted about a month ago that I tried one of my USB
high-speed web cameras in the Virtual Windows XP VM on Windows 7, and it
worked flawlessly. Now, all of a sudden, single machine WinDbg
debugging doesn’t sound like such a fantasy.

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

40

Did this involve the xp vm that’s (I hear) built in to win7?

Just curious?

Thanks,

mm