Suggestion for debugging

NTDEV
1

I’m trying to write some debug information to the screen in a 32-bit Native app that is executed when Autocheck is normally executed.

Because that duration is so short, it’s hard to see what is written to the screen.

Sleep() obviously can’t be called, and I haven’t been able to open a logfile to write debug information to disk. At this point, it may not even be a good idea to try and write anything to the disk at all. (???)

What else can be done to keep the information I’ve written to the screen visible for a longer period of time?

2

Connect kernel debugger and use debug output. DbgPrint() can be called from native app.

I guess at least SystemRoot should be available when native app is started and log file can be created there.

Best regards,

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

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@gmail.com[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, May 16, 2007 2:10 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Suggestion for debugging

I’m trying to write some debug information to the screen in a 32-bit Native app that is executed when Autocheck is normally executed.

Because that duration is so short, it’s hard to see what is written to the screen.

Sleep() obviously can’t be called, and I haven’t been able to open a logfile to write debug information to disk. At this point, it may not even be a good idea to try and write anything to the disk at all. (???)

What else can be done to keep the information I’ve written to the screen visible for a longer period of time?

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

3

you could try walking through the Sleep() call and see what native API it calls (NtDelayExecution/ZwDelayExecution)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, May 15, 2007 7:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Suggestion for debugging

I’m trying to write some debug information to the screen in a 32-bit Native app that is executed when Autocheck is normally executed.

Because that duration is so short, it’s hard to see what is written to the screen.

Sleep() obviously can’t be called, and I haven’t been able to open a logfile to write debug information to disk. At this point, it may not even be a good idea to try and write anything to the disk at all. (???)

What else can be done to keep the information I’ve written to the screen visible for a longer period of time?

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

4

In general:

dumpbin /exports ntdll.dll

  • this will give you a list of available functions that you may call.
    none of them are documented, and nothing about a native application is
    documented, so the working assumption is that any one is as safe or
    unsafe any other. this is not true in all cases.

  • from here, it can be useful to try and find the “Nt” equivalent of a
    DDK function, and in particular a “Zw” one. failing that, just search
    for something suggestive; in the case, I might try “timer.”

  • if you can, get a hold of “Windows NT/2000 Native API Reference” by
    Gary Nebbett. it is an excellent (and basically only) reference for the
    native API. unfortunately, I think it may be out of print.

  • failing that, just hit google, because that’s what you’re down to.
    there’s a good chance that for any function for which you search of the
    “Nt” variety, the first hit will be undocumented.ntinternals.net. The
    parameters are generally correct; the types are generally undefined, and
    those that are defined are commonly out of date or incomplete. but this
    is pretty much it as far as a general NT API reference goes, after the
    excellent Nebbett book.

I short, you might try NtInitializeTimer et. c. and see how that goes.

This is pretty much all there is, at least as far as I know. There are
very few people who have written more than one real native application,
even among those of us who make our living doing
drivers/internals/reverse-engineering, because there aren’t many reasons
at all to write one in the first place that can’t be handled,
considering the lack of any reference material on the subject of native
applications, more easily and much more safely in a driver.

best of luck,

mm

>> xxxxx@rivin.net 2007-05-16 00:53 >>>
you could try walking through the Sleep() call and see what native API
it calls (NtDelayExecution/ZwDelayExecution)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, May 15, 2007 7:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Suggestion for debugging

I’m trying to write some debug information to the screen in a 32-bit
Native app that is executed when Autocheck is normally executed.

Because that duration is so short, it’s hard to see what is written to
the screen.

Sleep() obviously can’t be called, and I haven’t been able to open a
logfile to write debug information to disk. At this point, it may not
even be a good idea to try and write anything to the disk at all. (???)

What else can be done to keep the information I’ve written to the
screen visible for a longer period of time?

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

5

>>if you can, get a hold of “Windows NT/2000 Native API Reference” by Gary Nebbett. it is an >>excellent (and basically only) reference for the native API. unfortunately, I think it may be out of
It’s not out of print yet, and I do have it. But it is so terse, it’s almost no help.

I’m trying to get the remote debugger going, so I can at least read the messages I’m printing, but that isn’t quite working yet. I’ve got a connection to the target machine, but the debugger gives up.

6

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@gmail.com[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, May 16, 2007 8:55 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Suggestion for debugging

>>if you can, get a hold of “Windows NT/2000 Native API Reference” by Gary Nebbett. it is an >>excellent (and basically only) reference for the native API. unfortunately, I think it may be out of
It’s not out of print yet, and I do have it. But it is so terse, it’s almost no help.

The book is reference and is very helpful. But it is necessary to know “how things work” from WDK and Win32 docs and from Russinovich and Solomon book. For this kind of development some experience is necessary. Sorry to say it but from your questions it seems you don’t have it. In this case the native reference may not be helpful.

I’m trying to get the remote debugger going, so I can at least read the messages I’m printing, but that isn’t quite working yet. I’ve got a connection to the target machine, but the debugger gives up.

So read the help and search this list archives to make it working. This is kind of experience I mean.

There is yet another way how to get debug output. DebugView tool is able to log boot messages. The drawback is they are stored in memory and are displayed after successful logon when the app is started. They can be also read from crashdump if system doesn’t boot successfully.

Best regards,

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

7

>>For this kind of development some experience is necessary. Sorry to say it but from your questions it >>seems you don’t have it.

That is why I am using this forum. This is the first time I tried writing anything low-level in Windows, and Native apps are an unusual case.

8

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@gmail.com[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, May 17, 2007 12:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Suggestion for debugging

That is why I am using this forum. This is the first time I tried writing anything low-level in Windows, and Native apps are an unusual case.

Native apps aren’t good start for low level development. There is almost no official documentation and I’d bet even most people here don’t have an experience even with native APIs calls from normal apps.

Forum is not a replacement for experience. You can get some advices but finally it is you who have to write and debug the code.

Why are you trying to develop native app i.e. what problem are you trying to solve? Maybe there is a simpler solution.

Best regards,

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

9

Good question, Michal. That is, what exactly is the dev trying to do.
The reason, in my opinion, that very few of us here have any experience
with this is that the cases where a native application is the best
answer, considering the lack of documentation, are few and far between.

mm

>> xxxxx@upek.com 2007-05-16 18:10 >>>

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
on behalf of xxxxx@gmail.com[SMTP:xxxxx@gmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, May 17, 2007 12:01 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Suggestion for debugging

That is why I am using this forum. This is the first time I tried
writing anything low-level in Windows, and Native apps are an unusual
case.

Native apps aren’t good start for low level development. There is
almost no official documentation and I’d bet even most people here don’t
have an experience even with native APIs calls from normal apps.

Forum is not a replacement for experience. You can get some advices but
finally it is you who have to write and debug the code.

Why are you trying to develop native app i.e. what problem are you
trying to solve? Maybe there is a simpler solution.

Best regards,

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

10

>>That is, what exactly is the dev trying to do.
I have posted this in another thread-

I need to send an VU ATA command (diagnostic) to the system drive, using the ATA Passthrough layer.

Since the drive is likely to take more time to return the information than Windows may be willing to allow- (ie, when it is fully booted), I am issuing the command at the time autocheck is would normally be started.

Actually, I’ve replaced the key in the registry where autocheck gets invoked, with my application.
Once the system is booted normally, the registry will be restored.

This ATA command needs to be issued over the ATA Passthrough layer, to avoid having to write any driver (or other code) that is system-specific, since it needs to be executed on systems with different motherboards/chipsets.

It’s just retrieving some diagnostic data the drive has collected.

11

Unfortunately, I can’t say that I know the first damn thing about ATA,
or even just storage drivers, for that matter. However, have you looked
at just writing a simple driver instead, as this approach would feature
(1) documentation; (2) some sort of sample code; (3) a debugger; (4)
more help from people on this list.

mm

>> xxxxx@gmail.com 2007-05-16 20:34 >>>
>That is, what exactly is the dev trying to do.
I have posted this in another thread-

I need to send an VU ATA command (diagnostic) to the system drive,
using the ATA Passthrough layer.

Since the drive is likely to take more time to return the information
than Windows may be willing to allow- (ie, when it is fully booted), I
am issuing the command at the time autocheck is would normally be
started.

Actually, I’ve replaced the key in the registry where autocheck gets
invoked, with my application.
Once the system is booted normally, the registry will be restored.

This ATA command needs to be issued over the ATA Passthrough layer, to
avoid having to write any driver (or other code) that is
system-specific, since it needs to be executed on systems with different
motherboards/chipsets.

It’s just retrieving some diagnostic data the drive has collected.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

12

>>However, have you looked at just writing a simple driver instead, as this approach would feature (1) >>documentation; (2) some sort of sample code; (3) a debugger; (4) more help from people on this st.

I agree with points 1,2,3,4 but have no knowledge about writing drivers.

The design constraints given to me are “not to write any code specific to any hardware”.
This is where the ATA passthrough comes in handy- at least from the perspective of a normal application.

Although- I don’t know if the ATA passthrough is even available from inside a Native App, or during the “autocheck time”.

13

It will be an up hill battle for a while. No question about it.
However, you, like almost everyone on this list, probably don’t know
anything about writing a native application either, and at least drivers
are documented. Also, my guess would be that if you were to post an
question about how to accomplish “ATA VU…” in a driver, I would be
willing to get that you would get some specific feedback, perhaps even
referring to an example. ATA pass through eventually will get reflected
to the kernel, probably in the form of an IRP. Someone on this list
knows how to emulate this. I just don’t know enough to help out here.

>> xxxxx@gmail.com 2007-05-16 21:38 >>>
>However, have you looked at just writing a simple driver instead, as
this approach would feature (1) >>documentation; (2) some sort of sample
code; (3) a debugger; (4) more help from people on this st.

I agree with points 1,2,3,4 but have no knowledge about writing
drivers.

The design constraints given to me are “not to write any code specific
to any hardware”.
This is where the ATA passthrough comes in handy- at least from the
perspective of a normal application.

Although- I don’t know if the ATA passthrough is even available from
inside a Native App, or during the “autocheck time”.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

14

ATA passthrough is SCSI pass through if IIRC and you can write a hw
agnostic driver that sends these pass through commands. Now, the issue
here is do you want to preinstall this driver, most likely as a filter
to the storage stack and have it running at all times, not only at boot
and when you need to retrieve the info? I don’t think you want that.
The native application does have the promise of only running when you
need it w/out perturbing the existing stack for the majority of the time
when this functionality is not needed.

Just a thought on the matter.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, May 16, 2007 7:14 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Suggestion for debugging

It will be an up hill battle for a while. No question about it.
However, you, like almost everyone on this list, probably don’t know
anything about writing a native application either, and at least drivers
are documented. Also, my guess would be that if you were to post an
question about how to accomplish “ATA VU…” in a driver, I would be
willing to get that you would get some specific feedback, perhaps even
referring to an example. ATA pass through eventually will get reflected
to the kernel, probably in the form of an IRP. Someone on this list
knows how to emulate this. I just don’t know enough to help out here.

>> xxxxx@gmail.com 2007-05-16 21:38 >>>
>However, have you looked at just writing a simple driver instead, as
this approach would feature (1) >>documentation; (2) some sort of sample
code; (3) a debugger; (4) more help from people on this st.

I agree with points 1,2,3,4 but have no knowledge about writing
drivers.

The design constraints given to me are “not to write any code specific
to any hardware”.
This is where the ATA passthrough comes in handy- at least from the
perspective of a normal application.

Although- I don’t know if the ATA passthrough is even available from
inside a Native App, or during the “autocheck time”.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

15

Assuming you are doing this from XP SP2 and above, you have options
available without having to resort to native apps. Vista improves on APTI,
but we have still found “issues” that have not been addressed by even Vista.

You can issue your vendor uniques (VU??) using pass through as long as you
are logged in as admin or from a service with the proper privildges. Or you
can use a filter driver attached to the storage stack. But … depending on
what your VUs are doing, most anything short of DOS will probably complain
if your function takes too much time. For instance, when developing our
secure commands using vendor uniques a few years ago, we found that issuing
a key-gen to a slave drive, which took about 90 minutes, would crash the OS
because the ATA bus would not permit access to the master on a page-fault
until the slave had completed the function. Thus, the recommendation would
be to ensure your drive is on another ATA channel than the boot drive. I’d
also recommend performing such functions before mounting the drive with a
file system.

–
The personal opinion of
Gary G. Little

wrote in message news:xxxxx@ntdev…
>>>However, have you looked at just writing a simple driver instead, as this
>>>approach would feature (1) >>documentation; (2) some sort of sample code;
>>>(3) a debugger; (4) more help from people on this st.
>
> I agree with points 1,2,3,4 but have no knowledge about writing drivers.
>
> The design constraints given to me are “not to write any code specific to
> any hardware”.
> This is where the ATA passthrough comes in handy- at least from the
> perspective of a normal application.
>
> Although- I don’t know if the ATA passthrough is even available from
> inside a Native App, or during the “autocheck time”.
>
>
>

16

Sorry, Doron, but APT is not SPT. They are similar, except that SPT just
works, and APT almost works most of the time. But the
permissions/restrictions are the same. If the OP wants to issue APT, the
options are app with admin privs, a service that isn't started under an
account that limits it's privs, or a helper driver, which, as you note, can
be completely HW agnostic.

Phil

Philip D. Barila Windows DDK MVP
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

"Doron Holan" wrote in message
news:xxxxx@ntdev...
ATA passthrough is SCSI pass through if IIRC and you can write a hw
agnostic driver that sends these pass through commands. Now, the issue
here is do you want to preinstall this driver, most likely as a filter
to the storage stack and have it running at all times, not only at boot
and when you need to retrieve the info? I don't think you want that.
The native application does have the promise of only running when you
need it w/out perturbing the existing stack for the majority of the time
when this functionality is not needed.

Just a thought on the matter.

d

17

The OP said the VU is "retrieving some diagnostic data". Unless the device
s doing a *lot* in generating that data (i.e. actually performing a surface
scan), it shouldn't take so long that the OS is going to get cranky. The MS
guys can confirm how long the paging mechanism will wait before bugchecking,
but I think it's somewhere in the 30 seconds or a miniute range. And if the
paging source is the same device that the APT command is currently
executiing on, XP SP2 appeared to be willing to wait indefinitely (more or
less, it was certainly willing to wait 4 hours+ at one point in our
development).

Phil

Philip D. Barila Windows DDK MVP
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

"Gary G. Little" wrote in message
news:xxxxx@ntdev...
> Assuming you are doing this from XP SP2 and above, you have options
> available without having to resort to native apps. Vista improves on APTI,
> but we have still found "issues" that have not been addressed by even
> Vista.
>
> You can issue your vendor uniques (VU??) using pass through as long as you
> are logged in as admin or from a service with the proper privildges. Or
> you can use a filter driver attached to the storage stack. But ...
> depending on what your VUs are doing, most anything short of DOS will
> probably complain if your function takes too much time. For instance, when
> developing our secure commands using vendor uniques a few years ago, we
> found that issuing a key-gen to a slave drive, which took about 90
> minutes, would crash the OS because the ATA bus would not permit access to
> the master on a page-fault until the slave had completed the function.
> Thus, the recommendation would be to ensure your drive is on another ATA
> channel than the boot drive. I'd also recommend performing such functions
> before mounting the drive with a file system.