I have the latest version of the WDK installed on my XP box and when
trying to build my driver, I get the follow error:
“obj_path is set for you. You may not set it.”. I’ve search through all
of the files in my project (using “*.*” as the file type filter) and
(except for the error logs) “obj_path” does not show up anywhere.
I’ve also started getting errors in ntddcdvd.h (“zero-sized array in
struct/union”). I’m using the C++ compiler.
Any ideas? I don’t really need to use the WDK, but on other posts people
suggested trying it to help diagnose a possible handle leak that is
preventing my driver from cleanly shutting down.
Thanks,
–Jeremy
What was the previous version of the WDK or DDK when
your driver compiled well?
If this is the first time you build your driver, please find a closest
WDK sample that matches your driver type and verify that it builds
for the target OS environment you choose.
Then compare how your SOURCE file differs from the WDK sample
( additional include and lib directories etc. )
Regards,
–PA
“Jeremy Chaney” wrote in message news:xxxxx@ntdev…
>I have the latest version of the WDK installed on my XP box and when trying to build my driver, I get the follow error:
> “obj_path is set for you. You may not set it.”. I’ve search through all of the files in my project (using “.” as the file
> type filter) and (except for the error logs) “obj_path” does not show up anywhere.
>
> I’ve also started getting errors in ntddcdvd.h (“zero-sized array in struct/union”). I’m using the C++ compiler.
>
> Any ideas? I don’t really need to use the WDK, but on other posts people suggested trying it to help diagnose a possible
> handle leak that is preventing my driver from cleanly shutting down.
>
>
> Thanks,
> --Jeremy
>
My experience is that converting to building with the WDK is
“excrutiatingly painful”. An existing driver family (six drivers
building over 175 source files) that built cleanly in all build
environments for the W2K3SP1 IFS Kit did not build in the WDK; it
required quite a lot of conditional work in order to make things
function properly. The best part is that I reported some of the issues
through the RC1 reporting process and they’ve either been ignored or -
my favorite - closed as “not reproducible”. Apparently they think I
fabricated the build logs.
One of the serious issues I had was dealing with functions that were
removed from the WDK that were previously available in the W2K3SP1 IFS
Kit - functions that are *in the OS* but are no longer in the LIB file
for the WDK. I’ll be writing up the mechanism I use to circumvent that
issue (thread-safe auto-initialization, dynamic loading with a fallback
function “just in case”.)
My other favorite were functions that have been converted to
“deprecated” in downlevel build environments that weren’t previously
deprecated. We use MmIsNonPagedSystemAddressValid because over the
years (we do a lot of file system filter driver work) we’ve had to code
around issues where bogus values are passed into our filter - and if it
crashes in our filter, it’s our fault - so we will usually probe the
address before checking the magic number in the structure (to ensure it
is ours). That function is now deprecated in downlevel build
environments. The dynamic linking, auto-initialization trick works for
that as well.
After spending 10 days working on it, I was able to get all 24 possible
build environments ( w2k, xp, w2k3 x86/x64, wlh x86/x64 - all checked
and free, we don’t build ia64 environments ) to work on both the W2KSP1
IFS Kit and the WDK but it’s amazingly fragile and I’ve had to go fix
things that have broken (they “worked” in the W2K3SP1 IFS environment
but broke in the WDK environment.)
But since we deliver toolkits to our customers we HAVE to make sure it
builds out of the box, so we’ll be living with both kits for at least
the next year or two.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Well I’m glad to hear that I’m not alone. I guess nobody else is having
problems with “obj_path”? I’ve switched back to KMDF1.1, but if I get
desperate for the driver testing features of the WDK (or if anyone has
any ideas as to how I can fix the compiler errors), I might switch back
and try to compile the samples and see if I get the same error.
Thanks,
–Jeremy
Tony Mason wrote:
My experience is that converting to building with the WDK is
“excrutiatingly painful”. An existing driver family (six drivers
building over 175 source files) that built cleanly in all build
environments for the W2K3SP1 IFS Kit did not build in the WDK; it
required quite a lot of conditional work in order to make things
function properly. The best part is that I reported some of the issues
through the RC1 reporting process and they’ve either been ignored or -
my favorite - closed as “not reproducible”. Apparently they think I
fabricated the build logs.
One of the serious issues I had was dealing with functions that were
removed from the WDK that were previously available in the W2K3SP1 IFS
Kit - functions that are *in the OS* but are no longer in the LIB file
for the WDK. I’ll be writing up the mechanism I use to circumvent that
issue (thread-safe auto-initialization, dynamic loading with a fallback
function “just in case”.)
My other favorite were functions that have been converted to
“deprecated” in downlevel build environments that weren’t previously
deprecated. We use MmIsNonPagedSystemAddressValid because over the
years (we do a lot of file system filter driver work) we’ve had to code
around issues where bogus values are passed into our filter - and if it
crashes in our filter, it’s our fault - so we will usually probe the
address before checking the magic number in the structure (to ensure it
is ours). That function is now deprecated in downlevel build
environments. The dynamic linking, auto-initialization trick works for
that as well.
After spending 10 days working on it, I was able to get all 24 possible
build environments ( w2k, xp, w2k3 x86/x64, wlh x86/x64 - all checked
and free, we don’t build ia64 environments ) to work on both the W2KSP1
IFS Kit and the WDK but it’s amazingly fragile and I’ve had to go fix
things that have broken (they “worked” in the W2K3SP1 IFS environment
but broke in the WDK environment.)
But since we deliver toolkits to our customers we HAVE to make sure it
builds out of the box, so we’ll be living with both kits for at least
the next year or two.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
I believe you are gettung the “obj_path” message because the source code you are building is sitting in the KMDF10\src tree from the KMDF 1.1 installation. The project.mk file in that tree sets obj_path, and it also requires you to use the set_wdf_env batch file- neither is needed for the WDK, and they conlict with each other.
Please move your source code outside that tree to use the WDK. Then just build it with a WDK build environment.
This might also fix your compiler errors (not certain of that one, though).
I’m not building in KMDF10 source tree, but I am including project.mk
from there (!include $(WDF_ROOT)\project.mk) in my main SOURCES file.
I’m not sure if this is correct, though. I can’t remember why I put that
line there… I can experiment with removing it, seeing what breaks (if
anything) and then proceed from there.
–Jeremy
xxxxx@microsoft.com wrote:
I believe you are gettung the “obj_path” message because the source code you are building is sitting in the KMDF10\src tree from the KMDF 1.1 installation. The project.mk file in that tree sets obj_path, and it also requires you to use the set_wdf_env batch file- neither is needed for the WDK, and they conlict with each other.
Please move your source code outside that tree to use the WDK. Then just build it with a WDK build environment.
This might also fix your compiler errors (not certain of that one, though).
You have it there because it is in the original 1.1 sources file.
The KMDF 1.1 builds needed this, because KMDF isn’t a built-in part of the Server SP1 DDK.
There’s no need to run the batch file to set WDF_ROOT, or to include project.mk when building from the WDK.
FWIW, I thought at first your source was in the original tree because (IIRC) build crawls up the tree to find these files (but maybe it doesn’t do that in WDK builds).
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeremy Chaney
Sent: Monday, September 18, 2006 6:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] build problem with WDK
I’m not building in KMDF10 source tree, but I am including project.mk
from there (!include $(WDF_ROOT)\project.mk) in my main SOURCES file.
I’m not sure if this is correct, though. I can’t remember why I put that
line there… I can experiment with removing it, seeing what breaks (if
anything) and then proceed from there.
–Jeremy
xxxxx@microsoft.com wrote:
I believe you are gettung the “obj_path” message because the source code you are building is sitting in the KMDF10\src tree from the KMDF 1.1 installation. The project.mk file in that tree sets obj_path, and it also requires you to use the set_wdf_env batch file- neither is needed for the WDK, and they conlict with each other.
Please move your source code outside that tree to use the WDK. Then just build it with a WDK build environment.
This might also fix your compiler errors (not certain of that one, though).
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer