ETW for 2000 --- driver hangs at remove

I am trying to enable ETW in my drivers for a USB device. I have a single
binary that runs on 2000 and XP, and I really want to keep it that way.
After paging through the recent thread here and through the toaster and
tracedrv samples, I got the driver to compile with a few debug prints
switched to trace messages. It loads and spits out those messages. So far,
so good.

The frown comes in when I try to unload the driver. The driver will not
unload. The driver below me (USBHUB) doesn’t return when I pass down the
IRP_MN_REMOVE_DEVICE. I followed the disassembly through a few levels of
USBHUB. It blocks in a call to
IoWMIRegistrationControl(WMIREG_ACTION_REREGISTER). According to the docs,
there must be a pending IRP_MJ_SYSTEM_CONTROL somewhere. But I don’t have
an WMI dispatch function. I used the WPP_SYSTEMCONTROL macro in
DriverEntry.

I used the “targeting Win2k” logic in this driver as done in toaster, so I
could build it under the XP build environment too. It works like a charm
when built that way, but of course, it won’t run on a Win2000 system. If I
build in the 2000 environment, the resulting driver hangs at removal on both
2000 and XP.

Does this problem ring any bells for anyone?

Chris Myers

WPP_SYSTEMCONTROL does not pass the IRP_MJ_SYSTEM control on to the lower level driver.

Please use WPP_SYSTEMCONTROL2
This has the form
WPP_SYSTEMCONTROL2(PDO, offset)
And is used something like
WPP_SYSTEMCONTROL2(DriverObject, FIELD_OFFSET(MY_DEVICE_EXTENSION, MYNextLowerDeviceObjectVariable));

The FIELD_OFFSET() routine gives the offset into the device extension to use for the devobj to forward requests to. If no such device exists, -1 should be passed in.

Or you can handle the IRP yourself and pass it on.

If the driver wishes is also required to handle System_Control IRP’s, the author must include code to call the WPP entry point directly from his own System Control dispatch routine, a convenient macro call WPP_TRACE_CONTROL is provided.

A code fragment might be something like - (an example with lower level driver processing is shown) -

case IRP_MN_REGINFO:

case IRP_MN_ENABLE_EVENTS:

case IRP_MN_DISABLE_EVENTS:

if (pDO == (PDEVICE_OBJECT)irpSp->Parameters.WMI.ProviderId) {

Status = irpSp->MinorFunction),WPP_TRACE_CONTROL(irpSp->MinorFunction),BufferSize,ReturnSize)

Irp->IoStatus.Status = Status;

Irp->IoStatus.Information = ReturnSize;

IoCompleteRequest( Irp, IO_NO_INCREMENT );

return Status;

} else if (We have a lower device) {

//

// Set current stack back one.

//

IoSkipCurrentIrpStackLocation( Irp );

//

// Pass the call to the next driver.

//

return IoCallDriver((PDEVICE_OBJECT)LowerDevice,Irp);

} else {

//unable to pass down – what to do?

Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;

Irp->IoStatus.Information = 0;

return Irp->IoStatus.Status;


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
Sent: Tuesday, April 13, 2004 9:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ETW for 2000 — driver hangs at remove

I am trying to enable ETW in my drivers for a USB device.? I have a single binary that runs on 2000 and XP, and I really want to keep it that way.? After paging through the recent thread here and through the toaster and tracedrv samples, I got the driver to compile with?a few debug prints switched to trace messages.? It loads and spits out those messages.? So far, so good.
?
The frown comes in when I try to unload the driver.? The driver will not unload.? The driver below me (USBHUB) doesn’t return when I pass down the IRP_MN_REMOVE_DEVICE.? I followed the disassembly through a few levels of USBHUB.? It blocks in a call to IoWMIRegistrationControl(WMIREG_ACTION_REREGISTER).? According to the docs, there must be a pending IRP_MJ_SYSTEM_CONTROL somewhere.? But I don’t have an WMI dispatch function.? I used the WPP_SYSTEMCONTROL macro in DriverEntry.?
?
I used the “targeting Win2k” logic in this driver as done in toaster, so I could build it under the XP build environment too.? It works like a charm when built that way, but of course, it won’t run on a Win2000 system.?? If I build in the 2000 environment, the resulting driver hangs at removal on both 2000 and XP.
?
Does this problem ring any bells for anyone?
?
Chris Myers
?

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

Ian,

Thanks a TON.

I have this working now, using the WPP_SYSTEMCONTROL2 macro. I did
encounter problems initially with this macro because I have been using DDK
3790. There is a bug in 3790’s km-init.tpl where the offset is used without
dereferencing the resulting pointer. This problem was corrected in
3790.WinHEC03, which I happily had on my system as well. I shifted the
build over there and it runs like a charm.

I will also note my pleasant surprise at being able to start a
logging session in Traceview before my driver is loaded. I tried it just
for grins, and out popped my test message after I plugged in my USB device.
Cool. Time to jump in with both feet!

Since the W2K implementation of ETW requires a device object, I
currently initialize the WPP goodies in StartDevice. I’m thinking about
experimenting with creating an extra (dummy) FDO in DriverEntry and using
that for ETW so that I can get trace coverage through the whole driver. It
seems to me that this should work. Worth a try anyway.

Chris Myers

-----Original Message-----
From: Ian Service [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, April 14, 2004 3:17 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

WPP_SYSTEMCONTROL does not pass the IRP_MJ_SYSTEM control on
to the lower level driver.

Please use WPP_SYSTEMCONTROL2
This has the form
WPP_SYSTEMCONTROL2(PDO, offset)
And is used something like
WPP_SYSTEMCONTROL2(DriverObject,
FIELD_OFFSET(MY_DEVICE_EXTENSION, MYNextLowerDeviceObjectVariable));

The FIELD_OFFSET() routine gives the offset into the device
extension to use for the devobj to forward requests to. If no
such device exists, -1 should be passed in.

Or you can handle the IRP yourself and pass it on.

If the driver wishes is also required to handle System_Control
IRP’s, the author must include code to call the WPP entry
point directly from his own System Control dispatch routine, a
convenient macro call WPP_TRACE_CONTROL is provided.

A code fragment might be something like - (an example with
lower level driver processing is shown) -

case IRP_MN_REGINFO:

case IRP_MN_ENABLE_EVENTS:

case IRP_MN_DISABLE_EVENTS:

if (pDO == (PDEVICE_OBJECT)irpSp->Parameters.WMI.ProviderId) {

Status =
irpSp->MinorFunction),WPP_TRACE_CONTROL(irpSp->MinorFunction),
BufferSize,ReturnSize)

Irp->IoStatus.Status = Status;

Irp->IoStatus.Information = ReturnSize;

IoCompleteRequest( Irp,
IO_NO_INCREMENT );

return Status;

} else if (We have a lower device) {

//

// Set current stack back one.

//

IoSkipCurrentIrpStackLocation( Irp );

//

// Pass the call to the next driver.

//

return
IoCallDriver((PDEVICE_OBJECT)LowerDevice,Irp);

} else {

//unable to pass down – what to do?

Irp->IoStatus.Status =
STATUS_INVALID_DEVICE_REQUEST;

Irp->IoStatus.Information = 0;

return Irp->IoStatus.Status;


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf >Of Chris
Myers
Sent: Tuesday, April 13, 2004 9:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ETW for 2000 — driver hangs at remove

I am trying to enable ETW in my drivers for a USB device.  I
have a single binary that runs on 2000 and XP, and I really
want to keep it that way.  After paging through the recent
thread here and through the toaster and tracedrv samples, I
got the driver to compile with a few debug prints switched to
trace messages.  It loads and spits out those messages.  So
far, so good.
 
The frown comes in when I try to unload the driver.  The
driver will not unload.  The driver below me (USBHUB) doesn’t
return when I pass down the IRP_MN_REMOVE_DEVICE.  I followed
the disassembly through a few levels of USBHUB.  It blocks in
a call to IoWMIRegistrationControl(WMIREG_ACTION_REREGISTER). 
According to the docs, there must be a pending
IRP_MJ_SYSTEM_CONTROL somewhere.  But I don’t have an WMI
dispatch function.  I used the WPP_SYSTEMCONTROL macro in
DriverEntry. 
 
I used the “targeting Win2k” logic in this driver as done in
toaster, so I could build it under the XP build environment
too.  It works like a charm when built that way, but of
course, it won’t run on a Win2000 system.   If I build in the
2000 environment, the resulting driver hangs at removal on
both 2000 and XP.
 
Does this problem ring any bells for anyone?
 
Chris Myers
 

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


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

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

> Since the W2K implementation of ETW requires a device object, I currently

initialize the WPP goodies in StartDevice. I’m thinking about
experimenting
with creating an extra (dummy) FDO in DriverEntry and using that for ETW
so that I can get trace coverage through the whole driver. It seems to me

that this should work. Worth a try anyway.

Thinking about this again after getting some sleep :-), I can see
that it won’t work because I don’t have a pointer to the DO below my driver
until AddDevice time.

Chris Myers

Not sure what you mean.

I don’t think that matters as this other DO is just for controlling traces. It doesn’t need to be one of your 'real" devices.

I understand other people have done similar things.


From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
Sent: Friday, April 16, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

Since the W2K implementation of ETW requires a device object, I currently
initialize the WPP goodies in StartDevice.? I’m thinking about experimenting
with creating an extra (dummy) FDO in DriverEntry and using that for ETW
so that I can get trace coverage through the whole driver.? It seems to me
that this should work.? Worth a try anyway.
??? Thinking about this again after getting some sleep :-), I can see that it won’t work because I don’t have a pointer to the DO below my driver until AddDevice time.?
Chris Myers


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

Yes, I’ve used “extra” device objects myself before, which is why I’m toying
with the idea here too. I think that I might get this working if I add a
skeleton WMI dispatch routine using WPP_TRACE_CONTROL, as you showed in the
code fragment. That should let me use the extra FDO for tracing WMI IRPs
and still pass through WMI IRPs targeting the drivers below mine.

Chris Myers

-----Original Message-----
From: Ian Service [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, April 16, 2004 12:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

Not sure what you mean.

I don’t think that matters as this other DO is just for
controlling traces. It doesn’t need to be one of your 'real" devices.

I understand other people have done similar things.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf >Of Chris
Myers
Sent: Friday, April 16, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

> Since the W2K implementation of ETW requires a device object, I
> currently
> initialize the WPP goodies in StartDevice.? I’m thinking
about experimenting
> with creating an extra (dummy) FDO in DriverEntry and using
that for ETW
> so that I can get trace coverage through the whole driver.?
It seems to me
> that this should work.? Worth a try anyway.
??? Thinking about this again after getting some sleep
:-), I can see that it won’t work because I don’t have a
pointer to the DO below my driver until AddDevice time.?
Chris Myers

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


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

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

Are you giving up the ability to have your driver unload? Please note
that if you create a device object in DriverEntry, then you will never
get a call to your unload routine, since that device object will always
exist. One negative to this is that the driver verifier (verifier.exe)
won’t be quite as useful to find leaks, since it can’t ensure you’ve
freed all your allocations on unload.

This is, of course, a design decision – do what your market needs
dictate. However, it is generally considered bad form to have your
driver around when the hardware isn’t currently in the system, and this
method also requires a reboot anytime the driver is updated (since it’s
in memory and can’t unload).

Hth,
.

-----Original Message-----
From: Chris Myers [mailto:xxxxx@quatech.com]
Sent: Friday, April 16, 2004 12:13 PM
Subject: RE: ETW for 2000 — driver hangs at remove

Yes, I’ve used “extra” device objects myself before, which is why I’m
toying with the idea here too. I think that I might get this working if
I add a skeleton WMI dispatch routine using WPP_TRACE_CONTROL, as you
showed in the code fragment. That should let me use the extra FDO for
tracing WMI IRPs and still pass through WMI IRPs targeting the drivers
below mine.

Chris Myers

-----Original Message-----
From: Ian Service [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, April 16, 2004 12:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

Not sure what you mean.

I don’t think that matters as this other DO is just for
controlling traces. It doesn’t need to be one of your 'real" devices.

I understand other people have done similar things.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf >Of Chris
Myers
Sent: Friday, April 16, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

> Since the W2K implementation of ETW requires a device object, I
> currently
> initialize the WPP goodies in StartDevice. I’m thinking
about experimenting
> with creating an extra (dummy) FDO in DriverEntry and using
that for ETW
> so that I can get trace coverage through the whole driver.
It seems to me
> that this should work. Worth a try anyway.
Thinking about this again after getting some sleep
:-), I can see that it won’t work because I don’t have a
pointer to the DO below my driver until AddDevice time.
Chris Myers

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


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

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

To avoid this problem, you can shutdown WPP and delete the WMI specific
devobj when the last FDO is removed. This will then preclude tracing
during unload, but if that is a caveat you are willing to work with, it
can be done.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry Gabryjelski
Sent: Monday, April 19, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ETW for 2000 — driver hangs at remove

Are you giving up the ability to have your driver unload? Please note
that if you create a device object in DriverEntry, then you will never
get a call to your unload routine, since that device object will always
exist. One negative to this is that the driver verifier (verifier.exe)
won’t be quite as useful to find leaks, since it can’t ensure you’ve
freed all your allocations on unload.

This is, of course, a design decision – do what your market needs
dictate. However, it is generally considered bad form to have your
driver around when the hardware isn’t currently in the system, and this
method also requires a reboot anytime the driver is updated (since it’s
in memory and can’t unload).

Hth,
.

-----Original Message-----
From: Chris Myers [mailto:xxxxx@quatech.com]
Sent: Friday, April 16, 2004 12:13 PM
Subject: RE: ETW for 2000 — driver hangs at remove

Yes, I’ve used “extra” device objects myself before, which is why I’m
toying with the idea here too. I think that I might get this working if
I add a skeleton WMI dispatch routine using WPP_TRACE_CONTROL, as you
showed in the code fragment. That should let me use the extra FDO for
tracing WMI IRPs and still pass through WMI IRPs targeting the drivers
below mine.

Chris Myers

-----Original Message-----
From: Ian Service [mailto:xxxxx@windows.microsoft.com]
Sent: Friday, April 16, 2004 12:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

Not sure what you mean.

I don’t think that matters as this other DO is just for
controlling traces. It doesn’t need to be one of your 'real" devices.

I understand other people have done similar things.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf >Of Chris
Myers
Sent: Friday, April 16, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

> Since the W2K implementation of ETW requires a device object, I
> currently
> initialize the WPP goodies in StartDevice. I’m thinking
about experimenting
> with creating an extra (dummy) FDO in DriverEntry and using
that for ETW
> so that I can get trace coverage through the whole driver.
It seems to me
> that this should work. Worth a try anyway.
Thinking about this again after getting some sleep
:-), I can see that it won’t work because I don’t have a
pointer to the DO below my driver until AddDevice time.
Chris Myers

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


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

You are currently
subscribed to ntdev as: xxxxx@quatech.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: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Doron, Henry,

I quickly noticed the problem with unload. The driver already kept
a count of the “real” device objects it had created, so it was easy to use
that count in the RemoveDevice handler to stop WPP and delete the tracing
device object. The tracing DO is created in DriverEntry. This approach
gets me trace coverage from AddDevice through RemoveDevice, leaving out only
DriverEntry and Unload. I’m pleased with the results so far, and I still
have a bit of hair left unpulled :-).

This event tracing is cool stuff that will absolutely help me
increase customer satisfaction, especially with mature drivers where the
issues that arise tend to be very obscure. Thanks for the help guys.

Best Regards,
Chris Myers

-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, April 19, 2004 12:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

To avoid this problem, you can shutdown WPP and delete the WMI
specific devobj when the last FDO is removed. This will then
preclude tracing during unload, but if that is a caveat you
are willing to work with, it can be done.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Monday, April 19, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ETW for 2000 — driver hangs at remove

Are you giving up the ability to have your driver unload?
Please note that if you create a device object in DriverEntry,
then you will never get a call to your unload routine, since
that device object will always exist. One negative to this is
that the driver verifier (verifier.exe) won’t be quite as
useful to find leaks, since it can’t ensure you’ve freed all
your allocations on unload.

This is, of course, a design decision – do what your market
needs dictate. However, it is generally considered bad form
to have your driver around when the hardware isn’t currently
in the system, and this method also requires a reboot anytime
the driver is updated (since it’s in memory and can’t unload).

Hth,
.

-----Original Message-----
From: Chris Myers [mailto:xxxxx@quatech.com]
Sent: Friday, April 16, 2004 12:13 PM
Subject: RE: ETW for 2000 — driver hangs at remove

Yes, I’ve used “extra” device objects myself before, which is
why I’m toying with the idea here too. I think that I might
get this working if I add a skeleton WMI dispatch routine
using WPP_TRACE_CONTROL, as you showed in the code fragment.
That should let me use the extra FDO for tracing WMI IRPs and
still pass through WMI IRPs targeting the drivers below mine.

Chris Myers

>-----Original Message-----
>From: Ian Service [mailto:xxxxx@windows.microsoft.com]
>Sent: Friday, April 16, 2004 12:48 PM
>To: Windows System Software Devs Interest List
>Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove
>
>
>Not sure what you mean.
>
>I don’t think that matters as this other DO is just for
>controlling traces. It doesn’t need to be one of your 'real" devices.
>
>I understand other people have done similar things.
>
>________________________________________
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf >Of Chris
>Myers
>Sent: Friday, April 16, 2004 9:19 AM
>To: Windows System Software Devs Interest List
>Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove
>
>
>> Since the W2K implementation of ETW requires a device object, I
>> currently
>> initialize the WPP goodies in StartDevice. I’m thinking
>about experimenting
>> with creating an extra (dummy) FDO in DriverEntry and using
>that for ETW
>> so that I can get trace coverage through the whole driver.
>It seems to me
>> that this should work. Worth a try anyway.
> Thinking about this again after getting some sleep
>:-), I can see that it won’t work because I don’t have a
>pointer to the DO below my driver until AddDevice time.
>Chris Myers
>—
>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
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently
>subscribed to ntdev as: xxxxx@quatech.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: xxxxx@windows.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: xxxxx@quatech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Doron and I talked about this issue a bit offline, and it seems his
solution is a bit more complex than originally thought. This stems from
the following problems:

  1. DriverEntry() could be immediately followed by PNP wanting to call
    Unload(). This would fail to work since there’s now a DO created in
    DriverEntry.

  2. It *might* be possible to get an AddDevice after the “last”
    RemoveDevice (timing dependent if a new device is added as an old one is
    being removed). There is still some debate about this as we’ve not
    reviewed any PNP code. The problem here is that you would no longer
    have the tracing DO created.

The way to “fix” this is to create the tracing DO in AddDevice IFF the
count is zero (and delete it if AddDevice fails), while also deleting
the tracing DO in the last RemoveDevice call. Of course, this now gives
you tracing only from AddDevice until RemoveDevice, which you can also
get without any of this extra work.

Why is this even considered? A rare race condition (timing dependent)
where a reference count could be left on the device object existed in
Win2k RTM. Since this is a rare race condition only affecting Win2k
(RTM, maybe some service packs also – haven’t checked), there is still
some debate as to whether the above “fix” is even worth doing. I have
written drivers for Win2k (shipping in-box, installed on most every
machine out there) which use tracing and I do not consider the issue
worth working around. Other people’s views obviously will vary.

.

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
From: Chris Myers [mailto:xxxxx@quatech.com]
Sent: Wednesday, April 21, 2004 7:29 AM
Subject: RE: ETW for 2000 — driver hangs at remove

Doron, Henry,

I quickly noticed the problem with unload. The driver already
kept a count of the “real” device objects it had created, so it was easy
to use that count in the RemoveDevice handler to stop WPP and delete the
tracing device object. The tracing DO is created in DriverEntry. This
approach gets me trace coverage from AddDevice through RemoveDevice,
leaving out only DriverEntry and Unload. I’m pleased with the results
so far, and I still have a bit of hair left unpulled :-).

This event tracing is cool stuff that will absolutely help me
increase customer satisfaction, especially with mature drivers where the
issues that arise tend to be very obscure. Thanks for the help guys.

Best Regards,
Chris Myers

-----Original Message-----
From: Doron Holan [mailto:xxxxx@windows.microsoft.com]
Sent: Monday, April 19, 2004 12:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove

To avoid this problem, you can shutdown WPP and delete the WMI
specific devobj when the last FDO is removed. This will then
preclude tracing during unload, but if that is a caveat you
are willing to work with, it can be done.

D

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Monday, April 19, 2004 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ETW for 2000 — driver hangs at remove

Are you giving up the ability to have your driver unload?
Please note that if you create a device object in DriverEntry,
then you will never get a call to your unload routine, since
that device object will always exist. One negative to this is
that the driver verifier (verifier.exe) won’t be quite as
useful to find leaks, since it can’t ensure you’ve freed all
your allocations on unload.

This is, of course, a design decision – do what your market
needs dictate. However, it is generally considered bad form
to have your driver around when the hardware isn’t currently
in the system, and this method also requires a reboot anytime
the driver is updated (since it’s in memory and can’t unload).

Hth,
.

-----Original Message-----
From: Chris Myers [mailto:xxxxx@quatech.com]
Sent: Friday, April 16, 2004 12:13 PM
Subject: RE: ETW for 2000 — driver hangs at remove

Yes, I’ve used “extra” device objects myself before, which is
why I’m toying with the idea here too. I think that I might
get this working if I add a skeleton WMI dispatch routine
using WPP_TRACE_CONTROL, as you showed in the code fragment.
That should let me use the extra FDO for tracing WMI IRPs and
still pass through WMI IRPs targeting the drivers below mine.

Chris Myers

>-----Original Message-----
>From: Ian Service [mailto:xxxxx@windows.microsoft.com]
>Sent: Friday, April 16, 2004 12:48 PM
>To: Windows System Software Devs Interest List
>Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove
>
>
>Not sure what you mean.
>
>I don’t think that matters as this other DO is just for
>controlling traces. It doesn’t need to be one of your 'real" devices.
>
>I understand other people have done similar things.
>
>________________________________________
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf >Of Chris
>Myers
>Sent: Friday, April 16, 2004 9:19 AM
>To: Windows System Software Devs Interest List
>Subject: RE: [ntdev] ETW for 2000 — driver hangs at remove
>
>
>> Since the W2K implementation of ETW requires a device object, I
>> currently
>> initialize the WPP goodies in StartDevice. I’m thinking
>about experimenting
>> with creating an extra (dummy) FDO in DriverEntry and using
>that for ETW
>> so that I can get trace coverage through the whole driver.
>It seems to me
>> that this should work. Worth a try anyway.
> Thinking about this again after getting some sleep
>:-), I can see that it won’t work because I don’t have a
>pointer to the DO below my driver until AddDevice time.
>Chris Myers
>—
>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
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently
>subscribed to ntdev as: xxxxx@quatech.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: xxxxx@windows.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: xxxxx@quatech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com