All of my test machines Vista and later have given up on firing breakpoints.
I get the message and that is it. Poking around in the code it seems that
RtlAssert looks at two bits of memory, one to fire the breakpoint and one do
the printing. On all my machines this value comes up at 1, but setting the
it to be 3 reverts behavior to “usual”.
‘ln’ doesn’t resolve the address to anything sensible and, given that this
is happening on many machines I’m taking a SWAG that I have changed
something in my windbg config - although the problem stays with me when I
move from 64 to 32 bit windbgs.
Any suggestions as to what I’ve done? Am I going to be embarrassed?
RtlAssert works only in checked version of windows. in free version of
windows, RtlAssert do nothing, although the .sys is debug version.
2009/10/20 Rod Widdowson
> These feels like a real 101 question. > > All of my test machines Vista and later have given up on firing > breakpoints. I get the message and that is it. Poking around in the code it > seems that RtlAssert looks at two bits of memory, one to fire the breakpoint > and one do the printing. On all my machines this value comes up at 1, but > setting the it to be 3 reverts behavior to “usual”. > > ‘ln’ doesn’t resolve the address to anything sensible and, given that this > is happening on many machines I’m taking a SWAG that I have changed > something in my windbg config - although the problem stays with me when I > move from 64 to 32 bit windbgs. > > Any suggestions as to what I’ve done? Am I going to be embarrassed? > > Rod > > — > WINDBG 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 >
“Rod Widdowson” wrote in message news:xxxxx@windbg… > These feels like a real 101 question. > > All of my test machines Vista and later have given up on firing > breakpoints. I get the message and that is it. Poking around in the code > it seems that RtlAssert looks at two bits of memory, one to fire the > breakpoint and one do the printing. On all my machines this value comes > up at 1, but setting the it to be 3 reverts behavior to “usual”. > > ‘ln’ doesn’t resolve the address to anything sensible and, given that this > is happening on many machines I’m taking a SWAG that I have changed > something in my windbg config - although the problem stays with me when I > move from 64 to 32 bit windbgs. > > Any suggestions as to what I’ve done? Am I going to be embarrassed? > > Rod >
>RtlAssert works only in checked version of windows
That is incorrect, RtlAssert works fine in the free build of Windows. You’re
probably confusing this with the ASSERT macro, which is only calls RtlAssert
in the checked build:
“??” wrote in message news:xxxxx@windbg… RtlAssert works only in checked version of windows. in free version of windows, RtlAssert do nothing, although the .sys is debug version.
2009/10/20 Rod Widdowson
These feels like a real 101 question.
All of my test machines Vista and later have given up on firing breakpoints. I get the message and that is it. Poking around in the code it seems that RtlAssert looks at two bits of memory, one to fire the breakpoint and one do the printing. On all my machines this value comes up at 1, but setting the it to be 3 reverts behavior to “usual”.
‘ln’ doesn’t resolve the address to anything sensible and, given that this is happening on many machines I’m taking a SWAG that I have changed something in my windbg config - although the problem stays with me when I move from 64 to 32 bit windbgs.
Any suggestions as to what I’ve done? Am I going to be embarrassed?
There is something that I don’t quite understand about the ASSERT macro.
The comment in wdm.h, line 7432 (WDK 7600 release) says:
“The ASSERT macro has been updated to be an expression instead of a
statement.”
so my guess is the author wanted to use it like that:
if ( !ASSERT(expr) ) do_something;
Then, in free version (DBG=0) it should be defined as #define ASSERT(exp) (exp)
But it is defined in line 7500 as #define ASSERT(exp) ((void)0)
that defeats the above use model of ASSERT and it’s other alias, RTL_VERIFY.
–pa
“Scott Noone” wrote in message news:xxxxx@windbg… >>RtlAssert works only in checked version of windows > > That is incorrect, RtlAssert works fine in the free build of Windows. > You’re probably confusing this with the ASSERT macro, which is only calls > RtlAssert in the checked build: > > #if DBG > > #define ASSERT( exp ) <br>> ((!(exp)) ? <br>> (RtlAssert( #exp, FILE , LINE , NULL ),FALSE) : <br>> TRUE) > > #else > #define ASSERT( exp ) ((void) 0) > #endif > > -scott > > – > Scott Noone > Consulting Associate > OSR Open Systems Resources, Inc. > http://www.osronline.com > > > > “??” wrote in message news:xxxxx@windbg… > RtlAssert works only in checked version of windows. in free version of > windows, RtlAssert do nothing, although the .sys is debug version. > > > > > 2009/10/20 Rod Widdowson > > These feels like a real 101 question. > > All of my test machines Vista and later have given up on firing > breakpoints. I get the message and that is it. Poking around in the code > it seems that RtlAssert looks at two bits of memory, one to fire the > breakpoint and one do the printing. On all my machines this value comes > up at 1, but setting the it to be 3 reverts behavior to “usual”. > > ‘ln’ doesn’t resolve the address to anything sensible and, given that this > is happening on many machines I’m taking a SWAG that I have changed > something in my windbg config - although the problem stays with me when I > move from 64 to 32 bit windbgs. > > Any suggestions as to what I’ve done? Am I going to be embarrassed? > > Rod > > — > WINDBG 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 > >
Doesn’t cure the problem. In hindsight the nature of the problem (code in
RtlAssert looking at a local flag) makes me thing that it is a layer above
the handling of the specific interrupts…
I’m glad it isn’t an obvious error and meanwhile I’ll get into the habit of
setting the variable to 3 when I need asserts to fire…
“Scott Noone” wrote in message news:xxxxx@windbg… >I don’t know how you would have done it, but does: > > sxe asrt > > Fix the issue? With the new Vista style asserts (int 2c vs int 3) you can > tell the debugger to ignore asserts, so that seems like it should do it. > > I’m not sure how you would have toggled this by accident though… > > -scott > > – > Scott Noone > Consulting Associate > OSR Open Systems Resources, Inc. > http://www.osronline.com > > > > “Rod Widdowson” wrote in message > news:xxxxx@windbg… >> These feels like a real 101 question. >> >> All of my test machines Vista and later have given up on firing >> breakpoints. I get the message and that is it. Poking around in the code >> it seems that RtlAssert looks at two bits of memory, one to fire the >> breakpoint and one do the printing. On all my machines this value comes >> up at 1, but setting the it to be 3 reverts behavior to “usual”. >> >> ‘ln’ doesn’t resolve the address to anything sensible and, given that >> this is happening on many machines I’m taking a SWAG that I have changed >> something in my windbg config - although the problem stays with me when I >> move from 64 to 32 bit windbgs. >> >> Any suggestions as to what I’ve done? Am I going to be embarrassed? >> >> Rod >> > > >