Event Tracing for Windows (ETW)

NTDEV
1

Michael:

Thanks for the background information.

My home brew trace information is good enough. Are there any developers
here who find ETW worth the effort?

Ralph Shnelvar

On Tue, 8 Feb 2005 20:23:29 +0100, you wrote:

> ----------
> From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Ralph Shnelvar[SMTP:xxxxx@dos32.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, February 08, 2005 3:28 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] IRQL = 0xFF mystery
>
> I can tell that DriverEntry has been enetered and has exited because of
> trace information that I leave around in memory. (Thanks, Michal Vodicka,
> for letting me know about ETW. I’ll probably replace my home-brewed trace
> code with ETW.)
>
Think twice about it. ETW is very good idea but the way how it is implemented makes it hard to use. From one side it is bloated overkill and from other it is too limited. The only real advantage against home-brewed traces is driver binary doesn’t contain trace messages and user can’t see the log. It can be even disadvantage for internal testing; with DbgPrint based traces you can simply start DbgView at any testing machine. I decided to stay with our home-brewed traces until MS makes ETW usable enough (i.e. probably forever :).

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

2

I use it all the time. I use flags and levels so that I can set the
filters to get the exact information I am looking for. However I have
always believed in the motto of “Garbage in, Garbage out” meaing, if you
don’t spend a fair amount of time coming up with a debug strategy and
thinking about what output would be helpful in analyzing a problem then all
your going to get out of your tracing is garbage…

–
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
“Ralph Shnelvar” wrote in message news:xxxxx@ntdev…
> Michael:
>
> Thanks for the background information.
>
> My home brew trace information is good enough. Are there any developers
> here who find ETW worth the effort?
>
> Ralph Shnelvar
>
> On Tue, 8 Feb 2005 20:23:29 +0100, you wrote:
>
>>> ----------
>>> From:
>>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>>> on behalf of Ralph Shnelvar[SMTP:xxxxx@dos32.com]
>>> Reply To: Windows System Software Devs Interest List
>>> Sent: Tuesday, February 08, 2005 3:28 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re: [ntdev] IRQL = 0xFF mystery
>>>
>>> I can tell that DriverEntry has been enetered and has exited because of
>>> trace information that I leave around in memory. (Thanks, Michal
>>> Vodicka,
>>> for letting me know about ETW. I’ll probably replace my home-brewed
>>> trace
>>> code with ETW.)
>>>
>>Think twice about it. ETW is very good idea but the way how it is
>>implemented makes it hard to use. From one side it is bloated overkill and
>>from other it is too limited. The only real advantage against home-brewed
>>traces is driver binary doesn’t contain trace messages and user can’t see
>>the log. It can be even disadvantage for internal testing; with DbgPrint
>>based traces you can simply start DbgView at any testing machine. I
>>decided to stay with our home-brewed traces until MS makes ETW usable
>>enough (i.e. probably forever :).
>>
>>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
>>
>>You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

3

For Software Tracing WPP simplifies using ETW for tracing. WPP is build
on top of ETW.

Search MSDN for WPP, there is extended documentation on the subject.
You will find in MSDN:
-Software Tracing FAQ
-documentation on the tools
-Samples
-debugger extension

For each provider GUID there are 255 levels, such as TRACE_LEVEL_ERROR,
etc. And 32 flags that you can define for tracing.

You can use Level and Flags to control tracing on your component, so
that you only get the tracing events you are interested in capturing. So
tracing can be enabled on your driver for say TRACE_LEVEL_WARNING and
Flags equal to one of the flags defined in your component.

The DDK sample shows the simplest form by just using flags, and ignoring
the Levels.

Thanks,
Jose Sua
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Wednesday, February 09, 2005 4:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Event Tracing for Windows (ETW)

Michael:

Thanks for the background information.

My home brew trace information is good enough. Are there any developers
here who find ETW worth the effort?

Ralph Shnelvar

On Tue, 8 Feb 2005 20:23:29 +0100, you wrote:

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Ralph Shnelvar[SMTP:xxxxx@dos32.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, February 08, 2005 3:28 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] IRQL = 0xFF mystery
>
> I can tell that DriverEntry has been enetered and has exited because
> of trace information that I leave around in memory. (Thanks, Michal
> Vodicka, for letting me know about ETW. I’ll probably replace my
> home-brewed trace code with ETW.)
>
Think twice about it. ETW is very good idea but the way how it is
implemented makes it hard to use. From one side it is bloated overkill
and from other it is too limited. The only real advantage against
home-brewed traces is driver binary doesn’t contain trace messages and
user can’t see the log. It can be even disadvantage for internal
testing; with DbgPrint based traces you can simply start DbgView at any
testing machine. I decided to stay with our home-brewed traces until MS
makes ETW usable enough (i.e. probably forever :).

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

4

Well first of all, I like and use ETW, but the documentation for using it or
WPP or whatever you want to call it, is scattered and incomplete. Doing
anything other than cutting and pasting from the ddk samples puts you out in
the woods alone in the dark. We’ve had this discussion here. Search for
“Moron ETW” and all the threads around that thread. Lots of good information
THERE, but precious little in the published stuff.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jose Sua
Sent: Wednesday, February 09, 2005 12:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Event Tracing for Windows (ETW)

For Software Tracing WPP simplifies using ETW for tracing. WPP is build on
top of ETW.

Search MSDN for WPP, there is extended documentation on the subject.
You will find in MSDN:
-Software Tracing FAQ
-documentation on the tools
-Samples
-debugger extension

For each provider GUID there are 255 levels, such as TRACE_LEVEL_ERROR, etc.
And 32 flags that you can define for tracing.

You can use Level and Flags to control tracing on your component, so that
you only get the tracing events you are interested in capturing. So tracing
can be enabled on your driver for say TRACE_LEVEL_WARNING and Flags equal to
one of the flags defined in your component.

The DDK sample shows the simplest form by just using flags, and ignoring the
Levels.

Thanks,
Jose Sua
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Wednesday, February 09, 2005 4:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Event Tracing for Windows (ETW)

Michael:

Thanks for the background information.

My home brew trace information is good enough. Are there any developers
here who find ETW worth the effort?

Ralph Shnelvar

On Tue, 8 Feb 2005 20:23:29 +0100, you wrote:

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Ralph Shnelvar[SMTP:xxxxx@dos32.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Tuesday, February 08, 2005 3:28 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] IRQL = 0xFF mystery
>
> I can tell that DriverEntry has been enetered and has exited because
> of trace information that I leave around in memory. (Thanks, Michal
> Vodicka, for letting me know about ETW. I’ll probably replace my
> home-brewed trace code with ETW.)
>
Think twice about it. ETW is very good idea but the way how it is
implemented makes it hard to use. From one side it is bloated overkill and
from other it is too limited. The only real advantage against home-brewed
traces is driver binary doesn’t contain trace messages and user can’t see
the log. It can be even disadvantage for internal testing; with DbgPrint
based traces you can simply start DbgView at any testing machine. I decided
to stay with our home-brewed traces until MS makes ETW usable enough (i.e.
probably forever :).

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Dear Mark Cariddi:

On Wed, 9 Feb 2005 08:28:52 -0500, you wrote:

I use it all the time. I use flags and levels so that I can set the
filters to get the exact information I am looking for. However I have
always believed in the motto of “Garbage in, Garbage out” meaing, if you
don’t spend a fair amount of time coming up with a debug strategy and
thinking about what output would be helpful in analyzing a problem then all
your going to get out of your tracing is garbage…

The one piece of information I want is: Has my DriverEntry been called more
than once?

What’s the least intrusive mechanism to determine this without the debugger
running (i.e. without, for instance, “/debugport=1394 /channel=33”).

Loren suggested “I suppose you could do something like allocating a named
object as soon as you get into driver entry” … but is there a less
intrusive way?

In terms of this Heisenbug, I quote my friend Jerry: What if there were no
hypotheticals?

Thanks,

Ralph Shnelvar

6

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Jose Sua[SMTP:xxxxx@windows.microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, February 09, 2005 6:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Event Tracing for Windows (ETW)

For each provider GUID there are 255 levels, such as TRACE_LEVEL_ERROR,
etc. And 32 flags that you can define for tracing.

You can use Level and Flags to control tracing on your component, so
that you only get the tracing events you are interested in capturing. So
tracing can be enabled on your driver for say TRACE_LEVEL_WARNING and
Flags equal to one of the flags defined in your component.

That’s why I said it is insufficient or not general enough. Our home-brewed (company wide) traces allows one level per debug area which is equivallent to flag here. I usually need to see traces for small part code only. So I set level for related areas to “trace” or “loud”, for possibly related areas to “debug” and left the rest at default “warning”. This way I can see detailed traces for relevant code and still see warning and errors in other code parts. If there is only one global level, the amount of info at “trace” or “loud” level would be enormous.

I understand I could emulate our approach with one GUID per area and this is what I call overkill :slight_smile:

Best regards,

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

7

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Mark Cariddi[SMTP:xxxxx@osr.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, February 09, 2005 2:28 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Event Tracing for Windows (ETW)

I use it all the time. I use flags and levels so that I can set the
filters to get the exact information I am looking for. However I have
always believed in the motto of “Garbage in, Garbage out” meaing, if you
don’t spend a fair amount of time coming up with a debug strategy and
thinking about what output would be helpful in analyzing a problem then all
your going to get out of your tracing is garbage…

Sure but what you describe is unrelated to ETW. Traces should be natural part of code to be useful and it isn’t important if ETW or something else is used to capture them.

My strategy is simple. We have three basic macros: block enter, leave and standard trace. Every function starts with enter macro which reports function name and all parameter values and ends with leave macro which reports function result(s) and elapsed time. Enter indents output, leave outdents. Inside the code I usually add traces to report unusual or important conditions. This way it is very easy to follow code flow and find what happened when problem occurs. It takes some time in coding phase but it pays off very soon in debugging phase. Good editor which generates enter/leave macros with all parameters automatically saves most of additional time.

Best regards,

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

8

If you use WPP to add software tracing to your driver, docs at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools
/hh/ddtools/ST_b1797333-3c08-4e78-8bea-fcee159dfdb5.xml.asp

You can enable tracing before the driver loads the stop it to read the
log file, or if the driver loads at boot time you can enable tracing
using the GlobalLogger.

To Start/Stop/Enable/Disable Tracing use: Tracelog.exe
To view the Traces use TraceFmt.exe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Wednesday, February 09, 2005 10:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Event Tracing for Windows (ETW)

Dear Mark Cariddi:

On Wed, 9 Feb 2005 08:28:52 -0500, you wrote:

I use it all the time. I use flags and levels so that I can set the
filters to get the exact information I am looking for. However I have

always believed in the motto of “Garbage in, Garbage out” meaing, if
you don’t spend a fair amount of time coming up with a debug strategy
and thinking about what output would be helpful in analyzing a problem
then all your going to get out of your tracing is garbage…

The one piece of information I want is: Has my DriverEntry been called
more than once?

What’s the least intrusive mechanism to determine this without the
debugger running (i.e. without, for instance, “/debugport=1394
/channel=33”).

Loren suggested “I suppose you could do something like allocating a
named object as soon as you get into driver entry” … but is there a
less intrusive way?

In terms of this Heisenbug, I quote my friend Jerry: What if there were
no hypotheticals?

Thanks,

Ralph Shnelvar

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

If extremely tight timing isn’t an issue, then DbgView would answer that
question on a running machine.

Won’t help on a crashed machine (stick something in the crash dump for
that… either use a full kernel dump and analyze your driver’s memory
with WinDbg or call KeRegisterBugCheckReasonCallback and write something
to the dump file yourself…

Ralph Shnelvar wrote:

Dear Mark Cariddi:

On Wed, 9 Feb 2005 08:28:52 -0500, you wrote:

>I use it all the time. I use flags and levels so that I can set the
>filters to get the exact information I am looking for. However I have
>always believed in the motto of “Garbage in, Garbage out” meaing, if you
>don’t spend a fair amount of time coming up with a debug strategy and
>thinking about what output would be helpful in analyzing a problem then all
>your going to get out of your tracing is garbage…

The one piece of information I want is: Has my DriverEntry been called more
than once?

What’s the least intrusive mechanism to determine this without the debugger
running (i.e. without, for instance, “/debugport=1394 /channel=33”).

Loren suggested “I suppose you could do something like allocating a named
object as soon as you get into driver entry” … but is there a less
intrusive way?

In terms of this Heisenbug, I quote my friend Jerry: What if there were no
hypotheticals?

Thanks,

Ralph Shnelvar

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

10

Dear Jose:

On Wed, 9 Feb 2005 13:54:21 -0800, you wrote:

If you use WPP to add software tracing to your driver, docs at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools
/hh/ddtools/ST_b1797333-3c08-4e78-8bea-fcee159dfdb5.xml.asp

Is this publicly available? Is the address correct? It doesn’t seem to
work for me.

Ralph Shnelvar

11

> Ralph asked:

The one piece of information I want is: Has my DriverEntry been called
more than once?

If you have an O-Scope, put a couple of lines at the very beginning of
your DriverEntry that write two bytes (back-to-back) on some hardware
port that you can get to (eg. FFh then 00h to I/O Port 80). If you are
getting into DriverEntry more than once you should see the scope show
more than one blip. Make sure you don’t arm the trigger until the boot
loader menu comes up (make sure you’ve enabled the menu).

MKE.

12

There’s a line-feed in the URL. Connect the two together and it should
work fine. MKE.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Wednesday, February 09, 2005 5:18 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Event Tracing for Windows (ETW)

Dear Jose:

On Wed, 9 Feb 2005 13:54:21 -0800, you wrote:

If you use WPP to add software tracing to your driver, docs at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtool
s
/hh/ddtools/ST_b1797333-3c08-4e78-8bea-fcee159dfdb5.xml.asp

Is this publicly available? Is the address correct? It doesn’t seem to
work for me.

Ralph Shnelvar

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

You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

13

URL is correct but too long and wrapped. Don’t click and copy&paste both parts to your browser address bar instead. Or search your local MSDN copy for WPP.

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 Ralph Shnelvar[SMTP:xxxxx@dos32.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, February 10, 2005 2:18 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Event Tracing for Windows (ETW)

Dear Jose:

On Wed, 9 Feb 2005 13:54:21 -0800, you wrote:

>If you use WPP to add software tracing to your driver, docs at
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools
>/hh/ddtools/ST_b1797333-3c08-4e78-8bea-fcee159dfdb5.xml.asp

Is this publicly available? Is the address correct? It doesn’t seem to
work for me.

Ralph Shnelvar

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

You are currently subscribed to ntdev as: xxxxx@upek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

14

Elad:

On Wed, 9 Feb 2005 17:43:17 -0800, you wrote:

There’s a line-feed in the URL. Connect the two together and it should
work fine. MKE.

Of course I had already done that.

I guess I need to say these things.

Ralph

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Wednesday, February 09, 2005 5:18 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Event Tracing for Windows (ETW)

Dear Jose:

On Wed, 9 Feb 2005 13:54:21 -0800, you wrote:

>If you use WPP to add software tracing to your driver, docs at
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtool
s
>/hh/ddtools/ST_b1797333-3c08-4e78-8bea-fcee159dfdb5.xml.asp

Is this publicly available? Is the address correct? It doesn’t seem to
work for me.

Ralph Shnelvar

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

You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

15

MKE:

On Wed, 9 Feb 2005 17:36:55 -0800, you wrote:

> Ralph asked:
> The one piece of information I want is: Has my DriverEntry been called
more than once?

If you have an O-Scope, put a couple of lines at the very beginning of
your DriverEntry that write two bytes (back-to-back) on some hardware
port that you can get to (eg. FFh then 00h to I/O Port 80). If you are
getting into DriverEntry more than once you should see the scope show
more than one blip. Make sure you don’t arm the trigger until the boot
loader menu comes up (make sure you’ve enabled the menu).

Ya know, I graduated as an EE more years than I care to think about.

I am clueless as to where to hook into to even see this … especially on a
laptop.

But, MKE, that’s a great suggestion and is truly minimally invasive …
until I short out the power supply. :slight_smile:

Plus, I’m interested in seeing if my DriverEntry is being entered twice
during driver installation (using the SetupDi functions) … so I don’t have
to deal with the boot menu issue.

MKE.

Ralph Shnelvar

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

16

I do realize that Ralph probably have solved the problem by now, but just
for completeness, I thought I’d add one possible solution to “How do I get
from the processor to the outside world”.

MKE:

On Wed, 9 Feb 2005 17:36:55 -0800, you wrote:

>> Ralph asked:
>> The one piece of information I want is: Has my DriverEntry been called
>more than once?
>
>If you have an O-Scope, put a couple of lines at the very beginning of
>your DriverEntry that write two bytes (back-to-back) on some hardware
>port that you can get to (eg. FFh then 00h to I/O Port 80). If you are
>getting into DriverEntry more than once you should see the scope show
>more than one blip. Make sure you don’t arm the trigger until the boot
>loader menu comes up (make sure you’ve enabled the menu).

Ya know, I graduated as an EE more years than I care to think about.

I am clueless as to where to hook into to even see this … especially on
a
laptop.

If the laptop has a parallel port, then that’s a good starting point. Bit
one on the parallel port is the second pin in (from the left) on the lower
row of pins, iirc. An OUT to port 0x378 will write to the parallel data
port. You can either just blip it, or let it go high when you enter, and
set it low when you exit some function. Of course, it’s a PCI access, which
means that the cycle to write to the port will take several dozen
nano-seconds, so for tight loops it’s probably not a good idea to stick one
of these in. But it can be used for profiling (for instance to figure out
worst case timing of some function) as well as to figure out if you get to
A, B or C in the code. There’s 8 pins to use, so you can get quite a lot of
information out that way.

If you haven’t got a better connector to attach to the parallel port, you
can usually build one from a paper-clip [as long as it’s a metal one, the
fancy coloured plastic triangular ones don’t work very well due to
infinitely high resistance ;-)], resistor “leg” or some soldering wire,
whichever is easier to find in your office/lab.

But, MKE, that’s a great suggestion and is truly minimally invasive …
until I short out the power supply. :slight_smile:

Shouldn’t be too much of a problem if you’re using the connector for the
parallel port.

Plus, I’m interested in seeing if my DriverEntry is being entered twice
during driver installation (using the SetupDi functions) … so I don’t
have
to deal with the boot menu issue.

If you have a memory scope or a simple logic analyzer, that should be a
doodle to catch if it’s happening once or twice or never…

[Of course, you probably will want to disconnect any printer you have
connected to the parallel port first ;-)]

–
Mats

>
>MKE.

Ralph Shnelvar

17

By any chance have you set a breakpoint in DriverEntry?

–
The personal opinion of
Gary G. Little

“Ralph Shnelvar” wrote in message news:xxxxx@ntdev…
> MKE:
>
> On Wed, 9 Feb 2005 17:36:55 -0800, you wrote:
>
> >> Ralph asked:
> >> The one piece of information I want is: Has my DriverEntry been called
> >more than once?
> >
> >If you have an O-Scope, put a couple of lines at the very beginning of
> >your DriverEntry that write two bytes (back-to-back) on some hardware
> >port that you can get to (eg. FFh then 00h to I/O Port 80). If you are
> >getting into DriverEntry more than once you should see the scope show
> >more than one blip. Make sure you don’t arm the trigger until the boot
> >loader menu comes up (make sure you’ve enabled the menu).
>
> Ya know, I graduated as an EE more years than I care to think about.
>
> I am clueless as to where to hook into to even see this … especially on
a
> laptop.
>
> But, MKE, that’s a great suggestion and is truly minimally invasive …
> until I short out the power supply. :slight_smile:
>
> Plus, I’m interested in seeing if my DriverEntry is being entered twice
> during driver installation (using the SetupDi functions) … so I don’t
have
> to deal with the boot menu issue.
>
> >
> >MKE.
>
> Ralph Shnelvar
>
> >
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
> >
> >You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

18

Mats:

Simple. Elegant. Awesome. Thanks!

And, yes, it looks like this problem has been resolved - somewhat - to my
satisfaction.

Nonetheless, this goes into my bag’o’tricks. My current bag’o’tricks is
almost empty since I used every single trick (except one) in this latest
bout with the bug monster.

What was the one I didn’t use, I hear you cry?

Answer: Tell my customers that they have a hardware problem.

Ralph Shnelvar

On Thu, 10 Feb 2005 15:03:26 +0000, you wrote:

I do realize that Ralph probably have solved the problem by now, but just
for completeness, I thought I’d add one possible solution to “How do I get
from the processor to the outside world”.

> MKE:
>
> On Wed, 9 Feb 2005 17:36:55 -0800, you wrote:
>
> >> Ralph asked:
> >> The one piece of information I want is: Has my DriverEntry been called
> >more than once?
> >
> >If you have an O-Scope, put a couple of lines at the very beginning of
> >your DriverEntry that write two bytes (back-to-back) on some hardware
> >port that you can get to (eg. FFh then 00h to I/O Port 80). If you are
> >getting into DriverEntry more than once you should see the scope show
> >more than one blip. Make sure you don’t arm the trigger until the boot
> >loader menu comes up (make sure you’ve enabled the menu).
>
> Ya know, I graduated as an EE more years than I care to think about.
>
> I am clueless as to where to hook into to even see this … especially on
a
> laptop.

If the laptop has a parallel port, then that’s a good starting point. Bit
one on the parallel port is the second pin in (from the left) on the lower
row of pins, iirc. An OUT to port 0x378 will write to the parallel data
port. You can either just blip it, or let it go high when you enter, and
set it low when you exit some function. Of course, it’s a PCI access, which
means that the cycle to write to the port will take several dozen
nano-seconds, so for tight loops it’s probably not a good idea to stick one
of these in. But it can be used for profiling (for instance to figure out
worst case timing of some function) as well as to figure out if you get to
A, B or C in the code. There’s 8 pins to use, so you can get quite a lot of
information out that way.

If you haven’t got a better connector to attach to the parallel port, you
can usually build one from a paper-clip [as long as it’s a metal one, the
fancy coloured plastic triangular ones don’t work very well due to
infinitely high resistance ;-)], resistor “leg” or some soldering wire,
whichever is easier to find in your office/lab.

>
> But, MKE, that’s a great suggestion and is truly minimally invasive …
> until I short out the power supply. :slight_smile:

Shouldn’t be too much of a problem if you’re using the connector for the
parallel port.

>
> Plus, I’m interested in seeing if my DriverEntry is being entered twice
> during driver installation (using the SetupDi functions) … so I don’t
have
> to deal with the boot menu issue.

If you have a memory scope or a simple logic analyzer, that should be a
doodle to catch if it’s happening once or twice or never…

[Of course, you probably will want to disconnect any printer you have
connected to the parallel port first ;-)]

19

Ralph Shnelvar wrote:

Nonetheless, this goes into my bag’o’tricks.

Here’s something else to add to your bag:

DON’T EMBED ASSEMBLY LANGUAGE IN WINDOWS DRIVERS.

It’s highly system specific, it’s WAAAAAY to easy to THINK you know what
you’re doing (“it worked on DOS”) but get an unexpected result (as in
INT 1 versus INT 3), and it won’t even compile in the x64 cross compiler.

It has NEVER been acceptable to use an INT 1 or an INT 3 or any other
such convention in a Windows NT driver. Really.

If I had a dollar for every person who said “But I’m experienced and I
know what I’m doing, and *I* can do xxxx…” (where “xxxx” is “write
directly to the base address registers in a DMA device” or “use this
particular assembler sequence” or “bypass the HAL” or…), I’d be a rich
man…

Peter
OSR

20

Peter Viscarola (OSR) wrote:

If I had a dollar for every person who said “But I’m experienced and I
know what I’m doing, and *I* can do xxxx…” (where “xxxx” is “write
directly to the base address registers in a DMA device” or “use this
particular assembler sequence” or “bypass the HAL” or…), I’d be a
rich man…

Oh, Peter. We all know that you ARE a rich man…

–