Is it possible to build an old WDM driver with the newest DDK? I do ot want to make code changes but don’t mind changing other files. I added the makefile.inc and changed to the newest makefile. I also created an inx file that was basically a copy of the wdf version of the driver I wrote. I tried commenting out the CoInstaller section and leaving it in. Updated the sources file to look like the one my wdf driver uses. Once I made these changes to my wdm driver it compiled without errors or warnings. Installing the driver results in a code 39. Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39) Does this I’m making a mistake or the code won’t work with the latest DDK? I seem to recall compiling a wdm driver w/o problem with one of the earliest wdf ddks.
Is is possible to build the same driver with the new DDK? If so what if any changes are necessary to use the newest ddk? Should I need to update the makefiles? Or am I just wasting my time? If it were up to me I wouldn’t bother but I’ve been asked to try.
Is it possible to build an old WDM driver with the newest DDK?
Yes. No problem at all. Sometimes you need changes to “sources” but
that’s it. Remember, a KMDF driver is just a WDM driver with an
additional framework.
I do ot want to make code changes but don’t mind changing other files. I added the makefile.inc and changed to the newest makefile. I also created an inx file that was basically a copy of the wdf version of the driver I wrote. I tried commenting out the CoInstaller section and leaving it in. Updated the sources file to look like the one my wdf driver uses.
If it’s not KMDF, then you certainly don’t want the KMDF co-installer.
Once I made these changes to my wdm driver it compiled without errors or warnings. Installing the driver results in a code 39. Windows cannot load the device driver for this hardware. The driver may be corrupted or missing. (Code 39) Does this I’m making a mistake or the code won’t work with the latest DDK?
Are you loading this on a 64-bit system? 64-bit drivers must be
digitally signed (with an acceptable certificate), or they will not
load. If you want to post the INF, we’ll take a look at it.
What build environment are you using, and what operating system are you
testing on? If you’re running on XP, you should use the Windows XP
Build Environment.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks. I was changing too many things. I just had to remove one line from my sources file. And the new ddk made me explicitly declare a for loop variable in the code.
Just one caution: remember that the new WDK has a different compiler.
It does very aggressive optimization and can break things.
Test well, try to disable optimization if weird problems show up.
–pa
We expect that the compiler generates correct code even when optimizations are enabled (this is how the OS itself is built after all). Bad codegen on optimization is most certainly a bug – and speaking from my own experience, that bug is usually in the program being compiled rather than the optimizer.
Not saying that compiler bugs don’t happen, but the vast, vast majority of issues tend to be a bug in the user’s program that the optimizer helped expose rather than optimizer code-gen issues.
I would not recommend disabling optimizations as a solution for unexplained behavior (with the WDK’s toolchain). Doing so often amounts to papering over a not-understood bug with a not-understood fix at the end of the day, often with the result that it’ll still happen but under different repro conditions that may be unknown to you.
If you do think you’ve found a real code gen bug, could you provide a minimal repro of the condition?
S (Msft)
-----Original Message-----
From: Pavel A. Sent: Friday, July 02, 2010 11:02 To: Windows System Software Devs Interest List Subject: Re:[ntdev] Build WDM
Just one caution: remember that the new WDK has a different compiler. It does very aggressive optimization and can break things. Test well, try to disable optimization if weird problems show up. –pa
Thank you, Mr. Johnson, nothing to report for now.
Let’s watch VC 2010 errata… there always is a room for one pesky last bug
As example of agressive optimization, I have some old code
that uses internal counters for various events, errors etc. The counters can
be read with debugger.
static counts[NCOUNTS];
extern void IncCount( unsigned n ) { ++counts[n]; }
New compilers (or maybe link) not only detect that the counts is unused
and eliminate it, but they inline calls to IncCount() in all compilation
units,
and then see that these calls do nothing, and eliminate them altogether.
With optimization enabled, nothing is counted, and cannot set breakpoint on
IncCount().
Declaring counts as volatile and IncCount as declspec(noinline) cured this.
Technically the old code had a bug - but from another POV, rebuild
with new kit broke old working code and required revision.
Regards,
–pa
“Skywing” wrote in message news:xxxxx@ntdev… > Pavel, > > We expect that the compiler generates correct code even when optimizations > are enabled (this is how the OS itself is built after all). Bad codegen > on optimization is most certainly a bug – and speaking from my own > experience, that bug is usually in the program being compiled rather than > the optimizer. > > Not saying that compiler bugs don’t happen, but the vast, vast majority of > issues tend to be a bug in the user’s program that the optimizer helped > expose rather than optimizer code-gen issues. > > I would not recommend disabling optimizations as a solution for > unexplained behavior (with the WDK’s toolchain). Doing so often amounts > to papering over a not-understood bug with a not-understood fix at the end > of the day, often with the result that it’ll still happen but under > different repro conditions that may be unknown to you. > > If you do think you’ve found a real code gen bug, could you provide a > minimal repro of the condition? > > - S (Msft) > > -----Original Message----- > From: Pavel A. > Sent: Friday, July 02, 2010 11:02 > To: Windows System Software Devs Interest List > Subject: Re:[ntdev] Build WDM > > > Just one caution: remember that the new WDK has a different compiler. > It does very aggressive optimization and can break things. > Test well, try to disable optimization if weird problems show up. > --pa > > > > — > 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 >
Yes, I’m afraid that this is legal and by design behavior. The compiler is entirely free to remove anything that it can prove is entirely unused by the program unless you have explicitly told it otherwise.
To that end, depending on the situation, you will need to use the “volatile” compiler keyword and/or the “/include:” linker directive in order to override the compiler and tell it that logic outside the program may depend on something that is otherwise extraneous to the program’s correct operation.
I would always recommend prior testing of a new compiler toolchain with previous project code to ensure that there were no (inadvertent or otherwise) assumptions on implementation specific behavior.
- S
-----Original Message----- From: Pavel A. Sent: Monday, July 05, 2010 18:21 To: Windows System Software Devs Interest List Subject: Re:[ntdev] Re:Build WDM
Thank you, Mr. Johnson, nothing to report for now. Let’s watch VC 2010 errata… there always is a room for one pesky last bug
As example of agressive optimization, I have some old code that uses internal counters for various events, errors etc. The counters can be read with debugger.
static counts[NCOUNTS];
extern void IncCount( unsigned n ) { ++counts[n]; }
New compilers (or maybe link) not only detect that the counts is unused and eliminate it, but they inline calls to IncCount() in all compilation units, and then see that these calls do nothing, and eliminate them altogether.
With optimization enabled, nothing is counted, and cannot set breakpoint on IncCount(). Declaring counts as volatile and IncCount as declspec(noinline) cured this.
Technically the old code had a bug - but from another POV, rebuild with new kit broke old working code and required revision.
Regards, --pa
“Skywing” wrote in message news:xxxxx@ntdev… > Pavel, > > We expect that the compiler generates correct code even when optimizations > are enabled (this is how the OS itself is built after all). Bad codegen > on optimization is most certainly a bug – and speaking from my own > experience, that bug is usually in the program being compiled rather than > the optimizer. > > Not saying that compiler bugs don’t happen, but the vast, vast majority of > issues tend to be a bug in the user’s program that the optimizer helped > expose rather than optimizer code-gen issues. > > I would not recommend disabling optimizations as a solution for > unexplained behavior (with the WDK’s toolchain). Doing so often amounts > to papering over a not-understood bug with a not-understood fix at the end > of the day, often with the result that it’ll still happen but under > different repro conditions that may be unknown to you. > > If you do think you’ve found a real code gen bug, could you provide a > minimal repro of the condition? > > - S (Msft) > > -----Original Message----- > From: Pavel A. > Sent: Friday, July 02, 2010 11:02 > To: Windows System Software Devs Interest List > Subject: Re:[ntdev] Build WDM > > > Just one caution: remember that the new WDK has a different compiler. > It does very aggressive optimization and can break things. > Test well, try to disable optimization if weird problems show up. > --pa > > > > — > 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 >
