Hello,
I have a specific system with two identical PCI cards installed in a PC running Windows XP (32 bits). The first card is on slot 1 and the second is on slot 2.
AddDevice is called twice: the first call is for the card on slot 1 and the second call for the card on slot 2.
However, the first IRP_MN_START_DEVICE request is sent for the card on slot 2, and the second is sent for the card on slot 1.
Note that on other systems the order of StartDevice matches the order of AddDevice.
What can cause this problem?
Is there a simply way to fix this? The driver needs to work only on Windows XP and Windows 2000 (32 bits).
I do not know if that matters or not, but the driver is actually a bus driver, and it has been written above the DriverWorks Driver Studio framework.
Thank you in advance,
Itai
First you cannot rely on the ordering period so you are out of luck.
Second DriverWorks has so many bugs that it is worthless so you are
really out of luck.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@rafael.co.il” wrote in message
news:xxxxx@ntdev:
> Hello,
> I have a specific system with two identical PCI cards installed in a PC running Windows XP (32 bits). The first card is on slot 1 and the second is on slot 2.
> AddDevice is called twice: the first call is for the card on slot 1 and the second call for the card on slot 2.
> However, the first IRP_MN_START_DEVICE request is sent for the card on slot 2, and the second is sent for the card on slot 1.
> Note that on other systems the order of StartDevice matches the order of AddDevice.
> What can cause this problem?
> Is there a simply way to fix this? The driver needs to work only on Windows XP and Windows 2000 (32 bits).
> I do not know if that matters or not, but the driver is actually a bus driver, and it has been written above the DriverWorks Driver Studio framework.
> Thank you in advance,
> Itai
Perhaps it’s my personal bigotry, but your first problem is your framework — Driver Studio. Driver Studio is broken and cannot pass driver verifier, and in this day and age is no longer supported. The recommendation is to dump Driver Studio, move on the WDF and get on with development.
I believe that you are not guaranteed any particular order of start, and depending on slot number controlling that is virtually a waste of time. It’s the author’s responsibility to do what is necessary to manage driver dependencies. Use an interface that allows the two drivers to exchange information, allowing the drivers to initialize in the proper order.
Gary G. Little
----- Original Message -----
From: xxxxx@rafael.co.il
To: “Windows System Software Devs Interest List”
Sent: Monday, March 7, 2011 10:15:34 AM
Subject: [ntdev] Two PCI cards StartDevice called in reverse order
Hello,
I have a specific system with two identical PCI cards installed in a PC running Windows XP (32 bits). The first card is on slot 1 and the second is on slot 2.
AddDevice is called twice: the first call is for the card on slot 1 and the second call for the card on slot 2.
However, the first IRP_MN_START_DEVICE request is sent for the card on slot 2, and the second is sent for the card on slot 1.
Note that on other systems the order of StartDevice matches the order of AddDevice.
What can cause this problem?
Is there a simply way to fix this? The driver needs to work only on Windows XP and Windows 2000 (32 bits).
I do not know if that matters or not, but the driver is actually a bus driver, and it has been written above the DriverWorks Driver Studio framework.
Thank you in advance,
Itai
—
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
>Is there a simply way to fix this? The driver needs to work only on Windows XP and Windows 2000 >(32 bits).
As already other people mention you can’t relay on PCI slots load order. And there is no way how you could force Windows to do it.
You should explain why do you need it. Give short description of your design. Probably there is the other solution which may help you.
Igor Sharovar
Hello,
I beleive I was misunderstood.
The start order is not important to our driver. Our driver just assumes that the IRP_MN_START_DEVICE order is identical to the AddDevice order.
Is there a reason why the IRP_MN_START_DEVICE order is different than the AddDevice order (On Windows XP)? Note that we observed this undesirable behavior only on some systems.
I understand that on Windows XP, drivers are not started asynchronously, so we expect the devices to be started on the same order of AddDevice.
Can Windows XP cause this behavior, or is it a bug in our driver? Maybe something else?
Yes, I beleive that the driver can be fixed not to depend on the start order. But it may us take some time to do that.
BTW: Gary, our driver uses a small subset of the framework, and passes Driver Verifier checks.
Thank you,
Itai
No there is no way to control this, you have lucked out so far.
As far as the framework even passing driver verifier just means you have
thousand of potential bugs instead of tens of thousands. I had a
customer who passed with the verifier and who was still crashing daily
in their driver. They asked to analyze the framework and using simple
tools like /W4 in the compiler, prefast and PC-Lint I documented over
10,000 places where the framework was going to crash if the right inputs
occurred or the just by calling a documented API. Common bugs were
things like passing uninitialized pointers in for output buffer, calling
routines that required passive level at DIRQL, and even some stack
allocations that were larger than the kernels stack (i.e. in one case
they created an array of 32KB on the stack). MY report concluded that
the framework was the worst piece of code to hit the windows kernel, and
since my client was using their drivers to control chemical plants they
needed to bail ASAP.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@rafael.co.il” wrote in message
news:xxxxx@ntdev:
> Hello,
> I beleive I was misunderstood.
> The start order is not important to our driver. Our driver just assumes that the IRP_MN_START_DEVICE order is identical to the AddDevice order.
> Is there a reason why the IRP_MN_START_DEVICE order is different than the AddDevice order (On Windows XP)? Note that we observed this undesirable behavior only on some systems.
> I understand that on Windows XP, drivers are not started asynchronously, so we expect the devices to be started on the same order of AddDevice.
> Can Windows XP cause this behavior, or is it a bug in our driver? Maybe something else?
> Yes, I beleive that the driver can be fixed not to depend on the start order. But it may us take some time to do that.
> BTW: Gary, our driver uses a small subset of the framework, and passes Driver Verifier checks.
> Thank you,
> Itai
The operative word there is “ASSUMED” in all of it’s definitions. The order you receive IRP_MN_START_DEVICE has no correlation to the order of AddDevice, hence any ordering you do because of AddDevice is based on fallacious information and is not guaranteed to remain the same across platforms. It’s a bug in your design.
Gary G. Little
----- Original Message -----
From: xxxxx@rafael.co.il
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 9, 2011 2:29:13 PM
Subject: RE:[ntdev] Two PCI cards StartDevice called in reverse order
Hello,
I beleive I was misunderstood.
The start order is not important to our driver. Our driver just assumes that the IRP_MN_START_DEVICE order is identical to the AddDevice order.
Is there a reason why the IRP_MN_START_DEVICE order is different than the AddDevice order (On Windows XP)? Note that we observed this undesirable behavior only on some systems.
I understand that on Windows XP, drivers are not started asynchronously, so we expect the devices to be started on the same order of AddDevice.
Can Windows XP cause this behavior, or is it a bug in our driver? Maybe something else?
Yes, I beleive that the driver can be fixed not to depend on the start order. But it may us take some time to do that.
BTW: Gary, our driver uses a small subset of the framework, and passes Driver Verifier checks.
Thank you,
Itai
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>I understand that on Windows XP, drivers are not started asynchronously, so we expect the devices >to be started on the same order of AddDevice.
It is wrong assumption. You could not control this. Even boot loader order is not guarantee in Windows, which may change on every boot.
Igor Sharovar
>Windows XP)? Note that we observed this undesirable behavior only on some systems.
Why “undesirable”? this is normal, since the start order is not a part of the contract.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Undesireable” meaning … The operating system does not function the way we THINK it should function, therefor the system functions incorrectly." Someone “assumed” that the order seen in one part of driver loading would be seen consistently in the system. I remember a discussion Jamie Hanrahan and I had in a seminar about the ordering of the Device Objects list. My “assumption” and hence how I wrote my driver was simply wrong.
Gary G. Little
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Thursday, March 10, 2011 4:17:34 AM
Subject: Re:[ntdev] Two PCI cards StartDevice called in reverse order
>Windows XP)? Note that we observed this undesirable behavior only on some systems.
Why “undesirable”? this is normal, since the start order is not a part of the contract.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer