Can driver use in Vista64,if dose not pass WHQL?

[Mark_Roddy]

Did the OP do a CLEAN build after deleting the explicit include paths to x86
header files from his sources file? I’m guessing not.

On Dec 5, 2007 1:25 PM, Tim Roberts wrote:

> xxxxx@hotmail.com wrote:
> > Hi MM,
> > Thank you for your suggestions!
> > I modified my source file as your suggestion,but the link error is still
> exist.
> > I think if there is no function bodies for
> KeInitializeSpinLock,KeGetCurrentIrql and KeTickCount in the lib for amd64?
> >
>
> That’s correct. They are macros. There shouldn’t BE any external
> references. That’s why this is so odd. It’s like you are using the x86
> include files with the amd64 libraries.
>
> If you are allowed to do so, why don’t you zip up your entire source
> directory and email it to me privately. I’ll build it in my 6000 WDK
> environment and see what happens.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>

–
Mark Roddy

[OSR_Community_User]

This is an excellent idea, Tim. I share your observations and curiosity
on this one. I reread the ‘relnotes.html’ file for the 6000 RTM WDK
this morning, and one thing that I noticed was this:

“The Custom installation option in Setup does not correctly manage the
many component interdependencies and as a result is not guaranteed to
produce a complete build environment.”

I’m not entirely sure what this means, but I had been wondering if his
installation itself was faulty, perhaps crossing paths with an older DDK.

Just a thought.

mm

Tim Roberts wrote:

xxxxx@hotmail.com wrote:
> Hi MM,
> Thank you for your suggestions!
> I modified my source file as your suggestion,but the link error is still exist.
> I think if there is no function bodies for KeInitializeSpinLock,KeGetCurrentIrql and KeTickCount in the lib for amd64?
>

That’s correct. They are macros. There shouldn’t BE any external
references. That’s why this is so odd. It’s like you are using the x86
include files with the amd64 libraries.

If you are allowed to do so, why don’t you zip up your entire source
directory and email it to me privately. I’ll build it in my 6000 WDK
environment and see what happens.

[OSR_Community_User]

Hi all,
Thank you!
Tim,I’m afraid I am not allowed to transmit the source code by my company.But thank you for your interntness also.
In the source code, we define one main header file “viausbmodem.h”,in this file,include some files:

#include <wdm.h>
#include <stddef.h>
#include <stdarg.h>
#include <ntddk.h>
#include <ntddser.h>
#include <wmistr.h>
#include <wmilib.h>
#include <windef.h>
#include <wmistr.h>
#include <wdmguid.h>
#include <string.h>
#include <usbdi.h>
#include <usbdlib.h>
#include <busbdbg.h>
-------------------------------------------------------------------------------
And other c files just #include “viausbmodem.h” .

The WDK I installed is “6000.16386.061101-2205-LRMWDK.A.ISO”,just download from microsoft’s web site.And I full install it in Vista64, there has directory "…WinDDK\6000\lib\wlh\amd64" ,ntstrsafe.lib and usbd.lib are in this folder.</busbdbg.h></usbdlib.h></usbdi.h></string.h></wdmguid.h></wmistr.h></windef.h></wmilib.h></wmistr.h></ntddser.h></ntddk.h></stdarg.h></stddef.h></wdm.h>

[David_J_Craig]

Did you ever notice that ntddk.h includes wdm.h? That may cause some
problems. I would review the release notes. You may include one or the
other but not both and that was even more critical in the old DDKs.

wrote in message news:xxxxx@ntdev…
> Hi all,
> Thank you!
> Tim,I’m afraid I am not allowed to transmit the source code by my
> company.But thank you for your interntness also.
> In the source code, we define one main header file “viausbmodem.h”,in this
> file,include some files:
> -------------------------------------------------------------------------------
> #include <wdm.h>
> #include <stddef.h>
> #include <stdarg.h>
> #include <ntddk.h>
> #include <ntddser.h>
> #include <wmistr.h>
> #include <wmilib.h>
> #include <windef.h>
> #include <wmistr.h>
> #include <wdmguid.h>
> #include <string.h>
> #include <usbdi.h>
> #include <usbdlib.h>
> #include <busbdbg.h>
> -------------------------------------------------------------------------------
> And other c files just #include “viausbmodem.h” .
>
> The WDK I installed is “6000.16386.061101-2205-LRMWDK.A.ISO”,just download
> from microsoft’s web site.And I full install it in Vista64, there has
> directory "…WinDDK\6000\lib\wlh\amd64" ,ntstrsafe.lib and usbd.lib are
> in this folder.
>
>
>
>
></busbdbg.h></usbdlib.h></usbdi.h></string.h></wdmguid.h></wmistr.h></windef.h></wmilib.h></wmistr.h></ntddser.h></ntddk.h></stdarg.h></stddef.h></wdm.h>

[OSR_Community_User]

You also are including at least on user mode file (windef.h). This file
defines _WIN32, and I think that may be how your getting a mix of X86
and X64. It also includes other files, some of which will set
WINVER/_WINNT_WIN32/et. c. and I believe that NTDDI_VERSION can be set
based on some combination of those. These are all guesses.

I’m amazed that this compiles; are you sure it does? Let me ask this
one more time: has this ever worked? If not, please, please, please
start over with a clean project. I realize that you didn’t mean to do
this, but it’s ridiculous, as all you need to do is include exactly one
of NTDDK.H, NTIFS.H or WDM.H, copy a generic sources file, and add any
project specific libraries to TARGETLIBS. That’s it.n By the time you
trace the preprocessed output of all the files involved, and the
massacre that is the build system, you could spend a week on this
problem. There’s no reason to do this. You could write a new sources
file in ten minutes.

So, in short, my best guess is to stop including windef.h. If that
doesn’t do it, I don’t the specific answer, and I’m giving up at this
point, because what you need to do is start over. The other thing that
I would recommend is to build one of the WDK sample projects for VISTA
X64 CHK. If it doesn’t work, you’ve done something very strange to your
machine, and you’re then down to uninstalling all DDKs/WDK’s and
reinstalling until a sample builds correctly.

Good luck,

mm

David Craig wrote:

Did you ever notice that ntddk.h includes wdm.h? That may cause some
problems. I would review the release notes. You may include one or the
other but not both and that was even more critical in the old DDKs.

wrote in message news:xxxxx@ntdev…
>> Hi all,
>> Thank you!
>> Tim,I’m afraid I am not allowed to transmit the source code by my
>> company.But thank you for your interntness also.
>> In the source code, we define one main header file “viausbmodem.h”,in this
>> file,include some files:
>> -------------------------------------------------------------------------------
>> #include <wdm.h>
>> #include <stddef.h>
>> #include <stdarg.h>
>> #include <ntddk.h>
>> #include <ntddser.h>
>> #include <wmistr.h>
>> #include <wmilib.h>
>> #include <windef.h>
>> #include <wmistr.h>
>> #include <wdmguid.h>
>> #include <string.h>
>> #include <usbdi.h>
>> #include <usbdlib.h>
>> #include <busbdbg.h>
>> -------------------------------------------------------------------------------
>> And other c files just #include “viausbmodem.h” .
>>
>> The WDK I installed is “6000.16386.061101-2205-LRMWDK.A.ISO”,just download
>> from microsoft’s web site.And I full install it in Vista64, there has
>> directory "…WinDDK\6000\lib\wlh\amd64" ,ntstrsafe.lib and usbd.lib are
>> in this folder.
>>
>>
>>
>>
>>
>
>
></busbdbg.h></usbdlib.h></usbdi.h></string.h></wdmguid.h></wmistr.h></windef.h></wmilib.h></wmistr.h></ntddser.h></ntddk.h></stdarg.h></stddef.h></wdm.h>

[Tim_Roberts]

xxxxx@hotmail.com wrote:

Hi all,
Thank you!
Tim,I’m afraid I am not allowed to transmit the source code by my company.But thank you for your interntness also.
In the source code, we define one main header file “viausbmodem.h”,in this file,include some files:

#include <wdm.h>
> #include <stddef.h>
> #include <stdarg.h>
> #include <ntddk.h>
> #include <ntddser.h>
> #include <wmistr.h>
> #include <wmilib.h>
> #include <windef.h>
> #include <wmistr.h>
> #include <wdmguid.h>
> #include <string.h>
> #include <usbdi.h>
> #include <usbdlib.h>
> #include <busbdbg.h>
> -------------------------------------------------------------------------------
> And other c files just #include “viausbmodem.h” .
>
> The WDK I installed is “6000.16386.061101-2205-LRMWDK.A.ISO”,just download from microsoft’s web site.And I full install it in Vista64, there has directory "…WinDDK\6000\lib\wlh\amd64" ,ntstrsafe.lib and usbd.lib are in this folder.
>

There has to be more to it than this. I copied-and-pasted that list to
a C file, and added the following:

NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
{
LONGLONG ll;
KeGetCurrentIrql();
KeQueryTickCount(&ll);
return 0;
}

I had to comment out the include of <busbdbg.h>; that must be one of
your own files. The resulting file compiled correctly. I then looked
at the pre-processor output file; it looks like this:

NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
{
LONGLONG ll;
KeGetCurrentIrql();
*((PULONG64)(&ll)) = *((volatile ULONG64
*)((0xFFFFF78000000000UI64 + 0x320)));
return 0;
}

This means the linker was able to find KeGetCurrentIrql, and that there
are NO references to KeTickCount at all. This tells me that your
libraries are screwed up.

Do you have a CL or LINK environment variable that might be overriding
the command-line parameters?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</busbdbg.h></busbdbg.h></usbdlib.h></usbdi.h></string.h></wdmguid.h></wmistr.h></windef.h></wmilib.h></wmistr.h></ntddser.h></ntddk.h></stdarg.h></stddef.h></wdm.h>

[Tim_Roberts]

Tim Roberts wrote:

…
NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
{
LONGLONG ll;
KeGetCurrentIrql();
KeQueryTickCount(&ll);
return 0;
}

I had to comment out the include of <busbdbg.h>; that must be one of
> your own files. The resulting file compiled correctly. I then looked
> at the pre-processor output file; it looks like this:
>
> NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
> {
> LONGLONG ll;
> KeGetCurrentIrql();
> *((PULONG64)(&ll)) = *((volatile ULONG64
> *)((0xFFFFF78000000000UI64 + 0x320)));
> return 0;
> }
>

And, by the way, I think it is fascinating that KeQueryTickCount on
amd64 expands to a dereference of an absolute address. I’m just stunned
that this passes the Windows kernel coding standards. It means that the
location of the tick counter variable can never change, ever. Every
amd64 version of Windows from now on will have to store the tick counter
at FFFF_F780_0000_0320.

Isn’t that what export symbols are for?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</busbdbg.h>

[Mark_Roddy]

That’s the shared memory region at the top of the VA space for all processes
for easy efficient access to stuff like the tick count. And while easy and
efficient, it is a massively fragile kludge hack. There is all sorts of gunk
up there. Truly a nightmare. 32bit has the equivalent nightmare at the top
of its address space.

On Dec 6, 2007 4:00 PM, Tim Roberts wrote:

> Tim Roberts wrote:
> > …
> > NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
> > {
> > LONGLONG ll;
> > KeGetCurrentIrql();
> > KeQueryTickCount(&ll);
> > return 0;
> > }
> >
> > I had to comment out the include of <busbdbg.h>; that must be one of
> > your own files. The resulting file compiled correctly. I then looked
> > at the pre-processor output file; it looks like this:
> >
> > NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
> > {
> > LONGLONG ll;
> > KeGetCurrentIrql();
> > *((PULONG64)(&ll)) = *((volatile ULONG64
> > *)((0xFFFFF78000000000UI64 + 0x320)));
> > return 0;
> > }
> >
>
> And, by the way, I think it is fascinating that KeQueryTickCount on
> amd64 expands to a dereference of an absolute address. I’m just stunned
> that this passes the Windows kernel coding standards. It means that the
> location of the tick counter variable can never change, ever. Every
> amd64 version of Windows from now on will have to store the tick counter
> at FFFF_F780_0000_0320.
>
> Isn’t that what export symbols are for?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>

–
Mark Roddy</busbdbg.h>

[Tim_Roberts]

Mark Roddy wrote:

That’s the shared memory region at the top of the VA space for all
processes for easy efficient access to stuff like the tick count. And
while easy and efficient, it is a massively fragile kludge hack. There
is all sorts of gunk up there. Truly a nightmare. 32bit has the
equivalent nightmare at the top of its address space.

Yes, but in 32-bit land, my driver does not have the absolute addresses
embedded into its binary! I don’t have a problem when ntoskrnl.exe has
hardcoded addresses. That’s perfectly fine. He is “the man”; he’s
setting the rules. But that’s not the case here. My driver BINARY has
to know this address.

Why wouldn’t they have exported KeTickCount from ntoskrnl.exe, and had
me link to it? The only cost is one extra fixup at driver load time.

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

[OSR_Community_User]

Hi all,
Thank you!
I try a project as Tim’s,and compile successful.And compile samples in WDK is also success.So the compile environment is ok.So I’ll try to find the error in our source code.
Thanks,
qihua

[OSR_Community_User]

Hi all,
Our project can compile success now!
Before link error is because of some not useful *.lib files in the project folder.It’s a mistake,I should check my folder. And why there had the *.lib files is a enigma to me.
Thank you all of you!
qihua

[Maxim_S_Shatskih]

SharedUserData was accessed by symbols I think, not by hardcoded addresses.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> That’s the shared memory region at the top of the VA space for all processes
> for easy efficient access to stuff like the tick count. And while easy and
> efficient, it is a massively fragile kludge hack. There is all sorts of gunk
> up there. Truly a nightmare. 32bit has the equivalent nightmare at the top
> of its address space.
>
> On Dec 6, 2007 4:00 PM, Tim Roberts wrote:
>
> > Tim Roberts wrote:
> > > …
> > > NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
> > > {
> > > LONGLONG ll;
> > > KeGetCurrentIrql();
> > > KeQueryTickCount(&ll);
> > > return 0;
> > > }
> > >
> > > I had to comment out the include of <busbdbg.h>; that must be one of
> > > your own files. The resulting file compiled correctly. I then looked
> > > at the pre-processor output file; it looks like this:
> > >
> > > NTSTATUS DriverEntry( PDRIVER_OBJECT x, PUNICODE_STRING y )
> > > {
> > > LONGLONG ll;
> > > KeGetCurrentIrql();
> > > *((PULONG64)(&ll)) = *((volatile ULONG64
> > > *)((0xFFFFF78000000000UI64 + 0x320)));
> > > return 0;
> > > }
> > >
> >
> > And, by the way, I think it is fascinating that KeQueryTickCount on
> > amd64 expands to a dereference of an absolute address. I’m just stunned
> > that this passes the Windows kernel coding standards. It means that the
> > location of the tick counter variable can never change, ever. Every
> > amd64 version of Windows from now on will have to store the tick counter
> > at FFFF_F780_0000_0320.
> >
> > Isn’t that what export symbols are for?
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > —
> > 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
> >
>
>
>
> –
> Mark Roddy
></busbdbg.h>

[OSR_Community_User]

I don’t think that this is the case:

#define KI_USER_SHARED_DATA 0xffdf0000

The only symbol I know of for SharedUserData, on x64 at least, is
MmSharedUserDataPte.

mm

Maxim S. Shatskih wrote:

SharedUserData was accessed by symbols I think, not by hardcoded addresses.

[OSR_Community_User]

Hi all,
When I try to install our driver,there is a error:

An error occurred during the installation of the device.The driver installation file for this device is missing a necessary entry.This may be because the INF was written for Windows 95 or later.

I had add “.ntamd64” in the INF file.Some section of the INF file is below:

[Version]
CatalogFile = ViaTelecomFile.cat
signature = “$CHICAGO$”
Class = USB
ClassGUID = {36FC9E60-C465-11CF-8056-444553540000}
Provider = %VIATelecom%
DriverVer = 12/07/2007,2.0.4

[Manufacturer]
%VIATelecom% = VIATelecom,NTamd64

[ControlFlags]
ExcludeFromSelect = * ; Remove all devices listed in this INF file

[VIATelecom]
%VIA_USB_HUB_DEVICE% = Composite.Dev, USB\VID_15EB&PID_0001

[VIATelecom.NTamd64]
%VIA_USB_HUB_DEVICE% = Composite.Dev.NTamd64, USB\VID_15EB&PID_0001

[DestinationDirs]
CoCopyINF.CopyFiles = 11 ; \Windows\System32

[SourceDisksFiles]
cocpyinf.dll = 1,

[SourceDisksNames]
1 = %SOURCE_DISKS_NAMES%,disk1

[Composite.Dev]
AddReg = Hub.AddReg
include = usb.inf

[Composite.Dev.NT]
AddReg = StandardHub.AddReg.NT
include = usb.inf

[Composite.Dev.NTamd64]
AddReg = StandardHub.AddReg.NTamd64
include = usb.inf

I want to know which “necessary entry” I had missed.
Thank you!
qihua

[Tim_Roberts]

xxxxx@hotmail.com wrote:

Hi all,
When I try to install our driver,there is a error:

An error occurred during the installation of the device.The driver installation file for this device is missing a necessary entry.This may be because the INF was written for Windows 95 or later.

I had add “.ntamd64” in the INF file. Some section of the INF file is below:

[Version]
CatalogFile = ViaTelecomFile.cat
signature = “$CHICAGO$”
Class = USB
ClassGUID = {36FC9E60-C465-11CF-8056-444553540000}
Provider = %VIATelecom%
DriverVer = 12/07/2007,2.0.4

[Manufacturer]
%VIATelecom% = VIATelecom,NTamd64

[ControlFlags]
ExcludeFromSelect = * ; Remove all devices listed in this INF file

[VIATelecom]
%VIA_USB_HUB_DEVICE% = Composite.Dev, USB\VID_15EB&PID_0001

[VIATelecom.NTamd64]
%VIA_USB_HUB_DEVICE% = Composite.Dev.NTamd64, USB\VID_15EB&PID_0001

[DestinationDirs]
CoCopyINF.CopyFiles = 11 ; \Windows\System32

[SourceDisksFiles]
cocpyinf.dll = 1,

[SourceDisksNames]
1 = %SOURCE_DISKS_NAMES%,disk1

[Composite.Dev]
AddReg = Hub.AddReg
include = usb.inf

[Composite.Dev.NT]
AddReg = StandardHub.AddReg.NT
include = usb.inf

[Composite.Dev.NTamd64]
AddReg = StandardHub.AddReg.NTamd64
include = usb.inf

I want to know which “necessary entry” I had missed.

What is it that you are trying to do here? If you really have an
ordinary USB hub that describes itself properly in its descriptors, then
you don’t need a driver or an INF file. The standard operating system
INF files will load usbhub.sys automatically.

To reference a section in another INF file, you need to use the “Needs”
statement. AddReg expects to find that section name in YOUR INF file,
and that’s almost certainly what led to your error. If you were trying
to refer to the “Hub.AddReg” section in USB.INF, then you need use
“Needs” to bring in a section in that INF file that includes the AddReg
line. For example:
[Composite.Dev]
Include = usb.inf
Needs = StandardHub.Dev

However, this is probably not going to lead to success. If your device
is a standard hub, then it will be supported automatically. If it is
not a standard hub, then usbhub.sys won’t know what to do with it.

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

[OSR_Community_User]

Hi Tim,
Thank you very much! When I add “Needs = StandardHub.Dev”,the system can install the hub device.
Our driver is not for hub, is for modem.The hub is a virtual device, and there are two device on the hub,one is modem. Maybe the framework is not so good, we will improve it in the future.
Thanks!
qihua

[Tim_Roberts]

xxxxx@hotmail.com wrote:

Thank you very much! When I add “Needs = StandardHub.Dev”,the system can install the hub device.
Our driver is not for hub, is for modem.The hub is a virtual device, and there are two device on the hub,one is modem. Maybe the framework is not so good, we will improve it in the future

So, this is just a normal composite device, where one interface is a
modem, and one interface is something else? In that case, you should
not mention your root device AT ALL. Skip it. The operating system
will automatically load usbccgp.sys to handle it, just because it is a
composite device. That driver will then enumerate the individual
interfaces so drivers may be loaded for them.

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

[Chris_Aseltine]

Tim Roberts wrote:

So, this is just a normal composite device, where one interface is a
modem, and one interface is something else? In that case, you should
not mention your root device AT ALL. Skip it. The operating system
will automatically load usbccgp.sys to handle it, just because it is
a composite device. That driver will then enumerate the individual
interfaces so drivers may be loaded for them.

I kind of got the impression they’ve actually embedded a USB hub in their device, except it doesn’t have the right descriptors so they need to load usbhub manually. In this case, writing an INF is probably the right thing to do.

Keep in mind you can’t really use usbccgp on a device that exposes a modem plus some other functions, because CDC ACM is actually two USB interfaces and usbccgp won’t know how to group them.

[Tim_Roberts]

xxxxx@gmail.com wrote:

Keep in mind you can’t really use usbccgp on a device that exposes a modem plus some other functions, because CDC ACM is actually two USB interfaces and usbccgp won’t know how to group them.

Doesn’t it? Usbccgp certainly understands how to group the related
interfaces in USB Audio Class and USB Video Class devices. CDC has been
around longer than Video Class, so I’d be surprised if it didn’t handle
it, although I admit I don’t know. With the considerable amount of USB
work we’ve done, communication class has never come up.

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

[Doron_Holan]

Usbccgp doesn’t know. Before IAD it had hard coded knowledge about grouping audio and video class devices, but any other multi interface function was hosed. With IAD this is now addressed generically and the device can describe functional groupings.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, December 11, 2007 9:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Can driver use in Vista64,if dose not pass WHQL?

xxxxx@gmail.com wrote:

Keep in mind you can’t really use usbccgp on a device that exposes a modem plus some other functions, because CDC ACM is actually two USB interfaces and usbccgp won’t know how to group them.

Doesn’t it? Usbccgp certainly understands how to group the related
interfaces in USB Audio Class and USB Video Class devices. CDC has been
around longer than Video Class, so I’d be surprised if it didn’t handle
it, although I admit I don’t know. With the considerable amount of USB
work we’ve done, communication class has never come up.

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

---

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