We need a little more information to help. You might want to post the
code that loads the driver which you commented out in the free build in
order to get it to work. Also, as Mark mentioned, WinDbg and some
KdPrint’s can go a long, long way here. If you already are using
KdPrint, you will to make a minor change in order for them to expand to
an actual call DbgPrint in a free build. You can either call DbgPrint
directly, or, immediately after including NTDDK.H, #undef it and then
#define it as it is in WDM.H, but without the conditional guards. If
you are not using any sort of tracing yet, then I would start by adding
some basic trace statements at the key points in each function of your
driver. For starters, at the entry and exit of DriverEntry and every
function (of yours) that it calls directly. This, with the help of
WinDbg or DbgView, should give you a better idea of how far you are
getting before it hangs. You could always just place a breakpoint at
DriverEntry, but this method will hopefully prevent some single stepping
by providing a better starting point.
Hope this helps,
mm
>> xxxxx@stratus.com 2007-03-06 08:41 >>>
In my experience optimization has rarely been the cause of problems.
Instead I’ve found dead code - code always executed in the debug build
that is never executed in the release build - to be the most common
release vs debug problem. That would be your second example - code
modification due to #ifdef DEBUG compilation constants.
Prefast can help here to identify release build problems. A debugger
can
help as well. And finally runtime tracing, using either release build
enabled debug prints or ETW, can be a huge help.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Monday, March 05, 2007 9:35 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DebugVSRelease
The most common release vs debug problem is that optimization can
eliminate
variable reads and/or writes that occur in the checked build. Look for
variables that should be volatile declared, especially in loops where a
variable might be promoted out of the loop when that was not the
intention.
wrote in message news:xxxxx@ntdev…
> As far as the app and OS is concerned there is no difference between
debug
> and release version of the driver. Debug version have some extra
symbols
> and extra code that you may have between #ifdef DEBUG - #endif.
There
may
> be some relevent code that is getting compiled away in the Release
> version.
>
> Check to see if you are not compiling away some relevent code in the
> Release version of the driver.
>
> - Crajyman - NathCorp
>
—
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
—
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