Hi,
I have a windows vista driver built on 6001.18001 vista DDK.
can i use the same driver on Windows 7? Will it have backward compatibility?
Do we need to use any other DDK specific for windows 7 drivers?
If not, what are all the portions of driver we need to analyaze and change to make it compatible for Windows.
Can anybody point me the correct direction?
In general a driver built for vista will run correctly on win7. You of
course should test your driver against win7. The whql test kit
requires testing against win7.
You would have to state what kind of driver this is for more specific
information.
You do not need to use the win7 WDK for your product.
Mark Roddy
On Thu, Jun 25, 2009 at 4:23 AM, wrote:
> Hi,
>
> I have a windows vista driver built on 6001.18001 vista DDK.
>
> can i use the same driver on Windows 7? Will it have backward compatibility?
> Do we need to use any other DDK specific for windows 7 drivers?
>
> If not, what are all the portions of driver we need to analyaze and change to make it compatible for Windows.
>
> Can anybody point me the correct direction?
>
> —
> 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
>
Hi,
I have a USB diver(generic) for vista.
I had done the WLK on windows 7. and i got one error:Unexpected error on “Device Install Check for Other Device Stability” the err msg is:
Could not load file or assembly ‘WDTF.Interop, Version=6.1.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its
dependencies. Strong name validation failed. (Exception from HRESULT:
0x8013141A)" CA=“2089606” LA=“2089757”
I found the errors from WLK logs. And from internet i found the work around in microsoft and msdn forums.So i think vista driver won’t be a problem on win7.
But i have another doubt, whether Windows XP driver is compatible with Win7? Because am getting some error while WLK and getting 5 to 6 blue screens.
Hope your reply…
Thanks in advance…
Nisheedh
Before we go through each version of Windows with this same question: In GENERAL, drivers are upwardly compatible. In other words, IN GENERAL, if you wrote a driver in Windows 2000 it will work on Windows 7.
Now, the catch is that the OPERATING SYSTEMs themselves don’t maintain their behavior completely from version to version – Bugs are fixed, features are added. Thus, the more removed a driver is (in terms of the OS for which it was designed/tested) from the current O/S release, the less likely it is that the driver will work successfully.
That really doesn’t mean the driver models aren’t compatible – It just means stuff has “changed.”
In my experience, most cases of incompatibility (where there’s just not an outright model, feature, or behavior change) come from drivers that weren’t designed correctly to begin with. These are drivers that I refer to as being “tested into working” as opposed to being “designed to work correctly” in the first place. Testing a driver into working (hacking, changing, hacking until the darn thing appears to function) is a lousy way to build stable code. Sadly, that exactly describes the process taken by many devs when they build WDM drivers.
Peter
OSR
It’s also worth noting that the WLK for Win7 is turning on WDF Verifier
for (I believe) the first time, and it’s using the one from the Win7
(i.e. KMDF 1.9) WDK.
In our case, this resulted in needing to upgrade our driver to KMDF 1.9
in order to pass WHQL. I don’t know whether that’s because of some quirk
in how we use KMDF, or if it would apply to many/all drivers, but I
somewhat suspect that latter, as it was failing in a fairly generic
place (no, I don’t remember off the top of my head).
We also had to change some things we were being sloppy about that
weren’t caught by previous versions of KMDF+Verifier.
Anyway, the lesson is: Logo-test your drivers early and often :-), and
use the new tools early and often, especially when a new OS is coming
out, even if you don’t plan to actually Logo them or switch to the new
WDK for a while.
xxxxx@osr.com wrote:
Before we go through each version of Windows with this same question: In GENERAL, drivers are upwardly compatible. In other words, IN GENERAL, if you wrote a driver in Windows 2000 it will work on Windows 7.
Now, the catch is that the OPERATING SYSTEMs themselves don’t maintain their behavior completely from version to version – Bugs are fixed, features are added. Thus, the more removed a driver is (in terms of the OS for which it was designed/tested) from the current O/S release, the less likely it is that the driver will work successfully.
That really doesn’t mean the driver models aren’t compatible – It just means stuff has “changed.”
In my experience, most cases of incompatibility (where there’s just not an outright model, feature, or behavior change) come from drivers that weren’t designed correctly to begin with. These are drivers that I refer to as being “tested into working” as opposed to being “designed to work correctly” in the first place. Testing a driver into working (hacking, changing, hacking until the darn thing appears to function) is a lousy way to build stable code. Sadly, that exactly describes the process taken by many devs when they build WDM drivers.
Peter
OSR
> In our case, this resulted in needing to upgrade our driver
to KMDF 1.9 in order to pass WHQL. I don’t know whether
that’s because of some quirk in how we use KMDF, or if it
would apply to many/all drivers, but I somewhat suspect that
latter, as it was failing in a fairly generic place (no, I
don’t remember off the top of my head).
My kmdf 1.7 based bus drivers work fine on win7/w2k8r2 for me.
Calvin Guan
Broadcom Corp.
Connecting Everything(r)
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Friday, June 26, 2009 1:30 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Using Windows vista driver on Windows 7Anyway, the lesson is: Logo-test your drivers early and often
:-), and
use the new tools early and often, especially when a new OS is coming
out, even if you don’t plan to actually Logo them or switch
to the new
WDK for a while.
Do you want to say WBF verifier works for you? It never worked for my
UMDF driver and behaves really crazy way. When I turn on (my) traces, I
see when it is running, my DllEntry is called for thread start and
immediate exit in the loop. Last time I played with it it caused
persistent 1 minute delay on driver unload :-# The only thing I wanted
to do was to enable traces. No way. I’m affraid it work only with WinDbg
which I don’t use (and MS people can’t understand ;-)).
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
I checked with the person who owns the WDF verifier tool. Here’s what he had
to say about the DllEntry calls -
"The DllEntry thread attach / detach is probably from the calls to
toolhelp32, used to enumerate drivers loaded in each host process. A
background thread probes to keep the UI up to date. The Win7 version sleeps
after each probe, but it is still fairly frequent, and since all we’re doing
is getting names of binaries loaded in the process, it will attach and
detach fairly quickly. "
Regarding the one-minute delay, is it possible that you had configured UMDF
to wait for one-minute during startup in order to allow you to connect a
debugger? If so, enabling traces would cause WDF Verifier to stop and
restart the UMDF driver manager service, which results in your device
getting stopped and restarted as well. If you’re seeing a one-minute delay
in this situation, it would be during the restart when UMDF is waiting for
the debugger to connect. This is a possible explanation, but I’m not sure if
it exactly matches what you observed.
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
>> Sent: Friday, June 26, 2009 1:30 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Using Windows vista driver on Windows 7
>>
>> Anyway, the lesson is: Logo-test your drivers early and often
>> :-), and
>> use the new tools early and often, especially when a new OS is coming
>> out, even if you don’t plan to actually Logo them or switch
>> to the new
>> WDK for a while.
>
> Do you want to say WBF verifier works for you? It never worked for my
> UMDF driver and behaves really crazy way. When I turn on (my) traces, I
> see when it is running, my DllEntry is called for thread start and
> immediate exit in the loop. Last time I played with it it caused
> persistent 1 minute delay on driver unload :-# The only thing I wanted
> to do was to enable traces. No way. I’m affraid it work only with WinDbg
> which I don’t use (and MS people can’t understand ;-)).
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Abhishek R
Sent: Friday, June 26, 2009 8:06 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Using Windows vista driver on Windows 7"The DllEntry thread attach / detach is probably from the calls to
toolhelp32, used to enumerate drivers loaded in each host process. A
background thread probes to keep the UI up to date. The Win7
version sleeps
after each probe, but it is still fairly frequent, and since
all we’re doing
is getting names of binaries loaded in the process, it will
attach and
detach fairly quickly. "
Thanks for the explanation. Yes, this is what I see. However, I’d expect
it ends after all binaries are enumerated and it is not the case. It
lasts until the tool is stoppped. Not a serious problem, though. Just an
annoyance and surprise; seeing something like this in traces doesn’t
create a confidence to the tool.
Regarding the one-minute delay, is it possible that you had
configured UMDF
to wait for one-minute during startup in order to allow you
to connect a
debugger? If so, enabling traces would cause WDF Verifier to stop and
restart the UMDF driver manager service, which results in your device
getting stopped and restarted as well. If you’re seeing a
one-minute delay
in this situation, it would be during the restart when UMDF
is waiting for
the debugger to connect. This is a possible explanation, but
I’m not sure if
it exactly matches what you observed.
I don’t think so. The delay occured always after device removal. The
exiting instance of WUDF host process was blocked for one minute.
Moreover, it blocked whole PnP stack for this time. Device Manager scan
for new devices, new device attached. There was a suspicious thread in
blocked process having ControlTraceW on the stack. Problem occured
always without WDF verifier running and I’m sure I checked if there
isn’t configured delay for debugger attach. I even checked it in the
registry because it was obvious candidate.
Unfortunately, I can’t reproduce it again. I restored the installation
(we weren’t sure it isn’t a problem in Win7 build) and problem
disappeared. I tried to play with WDF verifier again but it didn’t
occur. The only thing I have is a screenshort of suspicious thread stack
if you want.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> occur. The only thing I have is a screenshort of suspicious thread stack
if you want.
Sure, wouldn’t hurt to look at it, although I’m not sure if it will help
identify the cause.
Based on your description of the problem, it sounds like a request (either a
PNP request or an IO request which has been canceled by the issuer) was
stuck in the host process for a really long time. By default, the UMDF waits
for a minute before it times out waiting for that request to complete. When
the timeout occurs, it terminates the host process so that progress can be
made. If you are able to reproduce it in future, the best way to debug this
would be to configure UMDF to break into the debugger when the timeout
happens (http://msdn.microsoft.com/en-us/library/bb743209.aspx). Then, use
the !umirps debugger extension to see if any requests are still pending in
the host process and try to determine why.
If you need more detailed debugging instructions, you can look at the video
tutorials at -
http://www.microsoft.com/whdc/devtools/debugging/umdftraining.mspx
Part 4 of the tutorial has a piece on debugging these timeouts. Once the
video is launched, you can click “Non-responsive host” in the menu on the
left-hand side to jump directly to this piece.
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Abhishek R
>> Sent: Friday, June 26, 2009 8:06 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Using Windows vista driver on Windows 7
>>
>> "The DllEntry thread attach / detach is probably from the calls to
>> toolhelp32, used to enumerate drivers loaded in each host process. A
>> background thread probes to keep the UI up to date. The Win7
>> version sleeps
>> after each probe, but it is still fairly frequent, and since
>> all we’re doing
>> is getting names of binaries loaded in the process, it will
>> attach and
>> detach fairly quickly. "
>
> Thanks for the explanation. Yes, this is what I see. However, I’d expect
> it ends after all binaries are enumerated and it is not the case. It
> lasts until the tool is stoppped. Not a serious problem, though. Just an
> annoyance and surprise; seeing something like this in traces doesn’t
> create a confidence to the tool.
>
>> Regarding the one-minute delay, is it possible that you had
>> configured UMDF
>> to wait for one-minute during startup in order to allow you
>> to connect a
>> debugger? If so, enabling traces would cause WDF Verifier to stop and
>> restart the UMDF driver manager service, which results in your device
>> getting stopped and restarted as well. If you’re seeing a
>> one-minute delay
>> in this situation, it would be during the restart when UMDF
>> is waiting for
>> the debugger to connect. This is a possible explanation, but
>> I’m not sure if
>> it exactly matches what you observed.
>
> I don’t think so. The delay occured always after device removal. The
> exiting instance of WUDF host process was blocked for one minute.
> Moreover, it blocked whole PnP stack for this time. Device Manager scan
> for new devices, new device attached. There was a suspicious thread in
> blocked process having ControlTraceW on the stack. Problem occured
> always without WDF verifier running and I’m sure I checked if there
> isn’t configured delay for debugger attach. I even checked it in the
> registry because it was obvious candidate.
>
> Unfortunately, I can’t reproduce it again. I restored the installation
> (we weren’t sure it isn’t a problem in Win7 build) and problem
> disappeared. I tried to play with WDF verifier again but it didn’t
> occur. The only thing I have is a screenshort of suspicious thread stack
> if you want.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
I need to make a correction about the DllEntry calls referred to above, since it is potentially incorrect and I was the source of it. The code to determine UMDF client driver version may also be getting called in that case (e.g. to see if it had changed), and that requires (as described in one of my blog articles, but I’ll spare everyone the link) a call into a routine exported from the driver DLL.
If this had been reported earlier there perhaps could have been opportunity to do something about it.
Also, it lasts while the tool is running because (a) the auto-launch feaure requires determining when a new process starts so it can attach the debugger, and (b) as long as that was going to happen, using it to monitor everything and show device arrivals and departures seemed like a cheap and easy thing to do. It did not seem to have much of a downside as a choice.
Thanks for the explanation.
As for downsides… It is polling and polling is bad by definition 
Why don’t register device change notifications, instead? Guess what I
thought when started WDF verifier and DebugView screen started scrolling
because of hundreds traces from DllMain calls. Which I have turned on by
default to see driver loads and unloads.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Monday, June 29, 2009 3:10 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Using Windows vista driver on Windows 7Also, it lasts while the tool is running because (a) the
auto-launch feaure requires determining when a new process
starts so it can attach the debugger, and (b) as long as that
was going to happen, using it to monitor everything and show
device arrivals and departures seemed like a cheap and easy
thing to do. It did not seem to have much of a downside as a choice.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer