RamDisk on Windows7

Hi,
I am developing a RamDisk. Everything is ok but in Windows7 64bit the windows explorer crushes when i try to format the RamDrive by rightclicking on the drive. I can format the Ramdrive by rightclicking on it in any version of 32bit OS. To solve this problem i have modified the IOCTL’s now system become hanged when i want to format the RamDrive by right clicking. The drive is formattable from command prompt in Windows7 64bit OS. It will be enough if nothing happens when i click on format but the drive must be formattable from command prompt.
By,
Yuri Prime!!!

Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com.
http://mail.promotions.yahoo.com/newdomains/aa/

Some requires IOCTLs are not supported.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“shohug hasan” wrote in message news:xxxxx@ntdev…

Hi,
I am developing a RamDisk. Everything is ok but in Windows7 64bit the windows explorer crushes when i try to format the RamDrive by rightclicking on the drive. I can format the Ramdrive by rightclicking on it in any version of 32bit OS. To solve this problem i have modified the IOCTL’s now system become hanged when i want to format the RamDrive by right clicking. The drive is formattable from command prompt in Windows7 64bit OS. It will be enough if nothing happens when i click on format but the drive must be formattable from command prompt.
By,
Yuri Prime!!!

Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com.
http://mail.promotions.yahoo.com/newdomains/aa/

Sounds to me like you have some debugging to do.

If it were ME, I’d watch the incoming IRPs via the debugger and see what’s going wrong. You get a crash… start with analyze -v and find out what’s going wrong and where.

Sorry, but I have to ask: Why are you creating a RamDisk for Windows? This is the second such query we’ve seen in the past, oh, month or so. Given Windows provides a general-purpose demand paged virtual memory environment, a RamDisk would only seem to make sense for some very special use (like on Windows embedded, for example). And FOR that use, it seems like there are already RamDisks available that would do the job?

Peter
OSR

I am creating ramdisk as it is my job

— On Wed, 15/7/09, xxxxx@osr.com wrote:

> From: xxxxx@osr.com
> Subject: RE:[ntdev] RamDisk on Windows7
> To: “Windows System Software Devs Interest List”
> Date: Wednesday, 15 July, 2009, 8:11 PM
> Sounds to me like you have some
> debugging to do.
>
> If it were ME, I’d watch the incoming IRPs via the debugger
> and see what’s going wrong.? You get a crash… start
> with analyze -v and find out what’s going wrong and where.
>
> Sorry, but I have to ask: Why are you creating a RamDisk
> for Windows?? This is the second such query we’ve seen
> in the past, oh, month or so.? Given Windows provides a
> general-purpose demand paged virtual memory environment, a
> RamDisk would only seem to make sense for some very special
> use (like on Windows embedded, for example).? And?
> FOR that use, it seems like there are already RamDisks
> available that would do the job?
>
> Peter
> OSR
>
>
> —
> 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
>

New Email addresses available on Yahoo!
Get the Email name you’ve always wanted on the new @ymail and @rocketmail.
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/

I am debuging with Debugview and there is no problem with that. I have tested my driver with verifier but it do not crush. Sorry for desturbing you “xxxxx@osr.com” but i do not understand the lines tou wrote

“If it were ME, I’d watch the incoming IRPs via the debugger
and see what’s going wrong. You get a crash… start
with analyze -v and find out what’s going wrong and where.”

Would you please explain me the debuging process.

Thanks in advance

shohug hasan

— On Wed, 15/7/09, xxxxx@osr.com wrote:

> From: xxxxx@osr.com
> Subject: RE:[ntdev] RamDisk on Windows7
> To: “Windows System Software Devs Interest List”
> Date: Wednesday, 15 July, 2009, 8:11 PM
> Sounds to me like you have some
> debugging to do.
>
> If it were ME, I’d watch the incoming IRPs via the debugger
> and see what’s going wrong.? You get a crash… start
> with analyze -v and find out what’s going wrong and where.
>
> Sorry, but I have to ask: Why are you creating a RamDisk
> for Windows?? This is the second such query we’ve seen
> in the past, oh, month or so.? Given Windows provides a
> general-purpose demand paged virtual memory environment, a
> RamDisk would only seem to make sense for some very special
> use (like on Windows embedded, for example).? And?
> FOR that use, it seems like there are already RamDisks
> available that would do the job?
>
> Peter
> OSR
>
>
> —
> 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
>

New Email names for you!
Get the Email name you’ve always wanted on the new @ymail and @rocketmail.
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/

Don’t use DebugView to debug your driver. Use WinDbg. Set some breakpoints.

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

Peter
OSR

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.

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

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

Don’t use DebugView to debug your driver. Use WinDbg. Set
some breakpoints.

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

Hey? Peter? Sorry for a little flame but I can’t resist when YOU post
such a general and IMO wrong statement.

I debug all my Windows code including drivers with DebugView only for
long years. I never used WinDbg for live debugging and don’t remember
when set the last breakpoint at any platform I use (probably at Windows
some time before SoftICE died). Using debuggers and breakpoints is far
(1 - 3 orders of magnitude) less efficient for me. When debug my own
code; reverse engineering is another story.

Actually, I believe OP’s problem can be better debugged with traces than
with a debugger. If his driver contains good traces, of course.
Necessary good traces show all incoming IRPs, return codes, size of
returned info, contents etc. It should be immediatelly visible what
request caused shell32.dll crash (usually the last one seen). Achieving
the same with a debugger is painfully slow laborious task.

Best regards,

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

michal, you must be one awesome dev. i can’t get away with just debugging through traces alone, breaking into a debugger and actually stepping through code is much more reliable for me. so, how about this. we take peter’s statement as a generality and say that there are outliers that do not fit the generality and do whatever works best for them. i would also suggest that any new (driver) dev, no matter how much he protests about not being a part of the generality, should follow the general rule until he can sufficiently prove he is an outlier :slight_smile:

d

Doron,

I’m not awesome, I’m just lazy :wink: I hate repeated tedious tasks and
working with debugger is like this. Also, most problems I have to solve
are real-time where debuggers are completely useless. BTW, we made
traces mandatory in all our code. Our devs are free to use whatever they
want to debug their code but they have to write traces so anybody else
can debug their code if necessary without stepping through it. It allows
to quickly localize where the problem (reported as “it doesn’t work”)
really is and who is owner of this code.

The problem I have with Peter’s statement is following. Devs are
conservative and once they learn some technique, they tend to use it
forever. Even if it is inefficient and laborious. If you make it general
rule, most developers would use it wasting time and making their code
less reliable. With debugger you are concerned about local view whereas
traces give you global view which is much more important. I’d agree
debuggers are better for beginners who make local problems. But should a
driver writer be like this? I don’t think so. Driver developer should be
already experienced in coding and don’t need it. Of course, anybody can
make such a bug but experienced developer uses Prefast/lint and asserts
to catch them ASAP.

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@Microsoft.com
Sent: Friday, July 17, 2009 2:00 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RamDisk on Windows7

michal, you must be one awesome dev. i can’t get away with
just debugging through traces alone, breaking into a debugger
and actually stepping through code is much more reliable for
me. so, how about this. we take peter’s statement as a
generality and say that there are outliers that do not fit
the generality and do whatever works best for them. i would
also suggest that any new (driver) dev, no matter how much he
protests about not being a part of the generality, should
follow the general rule until he can sufficiently prove he is
an outlier :slight_smile:

d


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’m not quite as extreme about it as Michal is, but I use a debugger the same as he does, more or less - reverse engineering - and for the same reasons - I HATE stepping.

Big fan of traces…

mm

I forgot to add - though I would agree with Doron’s statement as well.

mm

Hi Michal,

You know… when I posted my reply, I was exchanging emails back-and-forth with Martin O’Brien. As soon I posted it, MM said: “You should have added ‘Except, of course, if your name is Michal Vodicka’…”

And he was certainly right.

I know you’re a print/trace fan. You, being an accomplished and respected dev, should (and will, regardless of what I write of course) use whatever you please. It works for you and I respect that. And I would never dream of giving you advice on driver debugging.

Here’s the thing, though: Using a debugger doesn’t mean you SHOULDN’T or CAN’T use print/trace. In fact, all methods of print/trace are available to you from within a debugger. But by using a debugger you can do MORE. You can step into code, view the state of variables across your code at any given time, follow the evidence, dynamically change values and see the effect.

But, if you limit yourself to print/trace you simply can’t do the things you can do from within the debugger. Sure, you can add more print/trace. But you can’t dynamically change the state of your code, or observe each small change as it occurs (without print/tracing every single line, of course).

While I would never tell somebody NOT to build good quality tracing into their code, likewise I would never counsel somebody to debug their driver without using a debugger. Debugging by JUST using print/trace is failing to exploit the full range of tools and aids available. I think it would be a serious dis-service to the less experienced readers on this list if I were to suggest to them that learning how to use the debugger effectively is not a useful skill.

So, I think you’re right: Tracing is good. It’s valuable. It’s sometimes even indispensable.

But, Michal… debugging with the debugger adds so much more.

Peter
OSR

Peter,

You know… when I posted my reply, I was exchanging emails
back-and-forth with Martin O’Brien. As soon I posted it, MM
said: “You should have added ‘Except, of course, if your name
is Michal Vodicka’…”

And he was certainly right.

:-))) I could name several other devs in our company but they don’t
write drivers.

Here’s the thing, though: Using a debugger doesn’t mean you
SHOULDN’T or CAN’T use print/trace.

OK, but it differs from your original statement a bit :slight_smile:

In fact, all methods of
print/trace are available to you from within a debugger. But
by using a debugger you can do MORE. You can step into code,
view the state of variables across your code at any given
time, follow the evidence, dynamically change values and see
the effect.

But, if you limit yourself to print/trace you simply can’t do
the things you can do from within the debugger. Sure, you
can add more print/trace. But you can’t dynamically change
the state of your code, or observe each small change as it
occurs (without print/tracing every single line, of course).

This is what I believe experienced developer shouldn’t need (when debug
own code). Of course, there are rare cases when it helps and makes
things faster when one makes a sloppy bug but finally you need to
recompile anyway. What you described is very good for beginners who
learn how to code but as I said in other mail, I believe such devs
shouldn’t write drivers.

While I would never tell somebody NOT to build good quality
tracing into their code, likewise I would never counsel
somebody to debug their driver without using a debugger.

Here is the main problem. People who use debugger usually (there are
exceptions, of course) don’t build good quality tracing to their code.
If they ever use traces, it is because debugger doesn’t work (races,
real-time problems) and they add them just to solve a particular
problem. Such traces can’t be used for general debugging. It is
necessary to use them as integral part of the code. As minimal
(mandatory in our company) is every function parameters and return
value. It is more work when you write code and unless (most) devs are
forced too, they don’t do it because don’t see immeditate gain. It is
write once use many but why to do it when there is a debugger.

Traces need some not-so-small initial investment. It isn’t only writing
them to the code, it is also necessary infrastructure. Areas, levels,
how to configure them. Something as ETW/WPP where MS failed because made
it too complicated and too primitive at once. Who’d think about it when
there is a simple and beginners’ friendly technique?

Debugging by JUST using print/trace is failing to exploit the
full range of tools and aids available. I think it would be a
serious dis-service to the less experienced readers on this
list if I were to suggest to them that learning how to use
the debugger effectively is not a useful skill.

Well, it is about priorities. What is the main and what is auxilary
tool. Traces can only work as main tool and I agree debugger can be
helpful in some scenarios (I don’t use one mainly because WinDbg is
pathetic after using SoftICE and debuggers at embedded platforms where I
develop are less than useless). Of course, WinDbg is great for crashdump
analysis.

But, Michal… debugging with the debugger adds so much more.

I don’t think so. I started programming with primitive traces because
there was no debugger this time. Later I discovered the first debugger
and really liked it as a beginner. Used debuggers for long time I slowly
returned to traces because some problems couldn’t be solved without
them. And mainly, I missed a global view; what is all the code in
various threads doing. During time I found I use debugger (SoftICE)
mainly as traces interceptor and rarely used anything else. Then SoftICE
died, I switched to DebugView and don’t miss it because reverse
enginnering isn’t my hobby anymore :slight_smile:

Do you remember how this discussion started long time before? It was
because Linus Torvalds’s aversion to kernel debugger in Linux. This time
I found it strange, as others. Now I understand him. Easy techniques can
be harmful when people stop on this level. And most Windows driver
developers do. Debuggers allow them to write miserable drivers which
work somewhat but not well. I even tend to believe Windows would be
better OS if MS devs don’t have kernel debugger available.

Hmm, it probably belongs to NTTALK which I haven’t subscribed. Yet? :wink:

Best regards,

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

If I replied to this, it really WOULD have to be on NTTALK. 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.

MOST Windows driver developers understand neither the architecture of the Windows I/O Subystem OR how to debug. I don’t think we can blame the quality of Windows drivers on the fact that there’s a comprehensive debugger. Most Linux drivers sucks pretty much like Windows drivers (just LOOK at how bad the audio subsystem is), and they don’t have a debugger.

By your argument above, we should all debug by the most difficult method possible. So, let’s forget print/trace, and forget debuggers, and debug with lights and switches, like back on the IBM 360 or the DECsystem 10.

If we were all debugging in assembler language, reading the instructions out in binary and single stepping from the front panel, then “Windows would be a better OS”???

Nah…

C’,mon Michal…

Peter
OSR

I miss the pink toggle switches …

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, July 16, 2009 10:37 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RamDisk on Windows7

If I replied to this, it really WOULD have to be on NTTALK. 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.

MOST Windows driver developers understand neither the architecture of the
Windows I/O Subystem OR how to debug. I don’t think we can blame the
quality of Windows drivers on the fact that there’s a comprehensive
debugger. Most Linux drivers sucks pretty much like Windows drivers (just
LOOK at how bad the audio subsystem is), and they don’t have a debugger.

By your argument above, we should all debug by the most difficult method
possible. So, let’s forget print/trace, and forget debuggers, and debug
with lights and switches, like back on the IBM 360 or the DECsystem 10.

If we were all debugging in assembler language, reading the instructions out
in binary and single stepping from the front panel, then “Windows would be a
better OS”???

Nah…

C’,mon Michal…

Peter
OSR


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

David R. Cattley wrote:

I miss the pink toggle switches …

And the blinky lights; don’t forget the blinky lights! Ever try to tell
if a Mac laptop is even DOING anything? Bah…

– mkj


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

Lights? Those were neon gas discharge bulbs so that they had fast response
time :wink:

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jones
Sent: Friday, July 17, 2009 8:52 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RamDisk on Windows7

David R. Cattley wrote:

I miss the pink toggle switches …

And the blinky lights; don’t forget the blinky lights! Ever try to tell
if a Mac laptop is even DOING anything? Bah…

– mkj


//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________


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

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

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

OK, let’s forget about Linux, I like it exactly as you do :wink:

By your argument above, we should all debug by the most
difficult method possible. So, let’s forget print/trace, and
forget debuggers, and debug with lights and switches, like
back on the IBM 360 or the DECsystem 10.

If we were all debugging in assembler language, reading the
instructions out in binary and single stepping from the front
panel, then “Windows would be a better OS”???

No, my argument was different but I probably expressed it badly. Next
try.

Debuggers are simple to use and allow to solve simple problems. Usually
local coding problems. Nothing bad with it unless developers freeze at
this level and I’m affraid most devs do. OS is complicated beast and for
successful debugging local view is quite insufficient. Traces allow more
general view with any desired granularity if used properly. You can see
what the whole OS is doing, how modules interracts, if there are races
and so on. If they’re used as integral part of the code. And they
aren’t. My point is if there is no kernel debugger available, MS would
have to develop different general debugging technique and I believe
they’d use traces. They’d have to be forced to use them regularly in all
the code and it would be much easier to debug complicated problems for
both of them and us. We can see such attempts, randomly used debug
prints in random modules configured random way, now usually replaced by
WPP which is even worse. Still it is quite insufficient because devs are
used to debuggers. If there are good traces, we wouldn’t hear “we can’t
reproduce the problem locally so problem doesn’t exist”. Instead, they’d
tell us how to configure traces for this kind of problems, ask us
reproduce it and send them results. This is what we do when have a
problem at customers’ site and it saves a lot of time.

Well, I don’t think I’d convince anybody. Traces are “lazy man
technique” and most devs are dilligent and prefer single stepping so
they have an illusion of beeing active. I just wanted to point out your
original statement:

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

can’t be applied even for a newbie (I know you corrected it later). The
advice should be debug your code; any way you’re used to. Examine what
it is doing and what leads to the problem. I wouldn’t underestimate an
ability of a new member of this list to use traces. Even a driver
developer newbie can be (and should be…) very experienced developer
who knows how to debug code efficiently.

Best regards,

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

> I know you’re a print/trace fan.

I mainly debug my user-mode code by adding printf() or similar statements with some expressions to the point around the probable bug. Extremely powerful method. Recently I discover one bug by adding fopen/fwrite/fclose and dumping some data to the external file.

With kmode debugging, I mainly use a) crash dump analyzis with data structures review b) breakpoints, including the extremely powerful feature of “ba”.

I nearly never use single-stepping - just no need in it.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com