Hi,
I am experiencing strange issue with Windows 8.1. (only on 8.1)
When driver verifier is ON, I got DriverEntry’s RegistryPath contain
invalid string value when driver verifier is turned ON.
Is that driver verifier injecting invalid string intentionally?
How should I handle it?
Couldn’t find anything about it on DDK documentation or google.
thanks.
–
Bandu
xxxxx@gmail.com
Invalid in what way?
Kris
On Wed, Dec 11, 2013 at 1:51 PM, Bandu wrote:
> Hi,
>
> I am experiencing strange issue with Windows 8.1. (only on 8.1)
> When driver verifier is ON, I got DriverEntry’s RegistryPath contain invalid
> string value when driver verifier is turned ON.
>
> Is that driver verifier injecting invalid string intentionally?
> How should I handle it?
> Couldn’t find anything about it on DDK documentation or google.
>
>
> thanks.
>
> –
> Bandu
> xxxxx@gmail.com
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
–
Kris
pRegistryPath->Length 0x47f8
pRegistryPath->MaximumLength 0x2075
pRegistryPath->Buffer 0x0
Length and MaximumLenght values are random value on each loading.
Is that effect of Verifier’s DDI compliance test (safe string setting)?
But how I understand is that, if RegistryPath is null or invalid, I can’t
load my driver. right?
thanks
Bandu
On Wed, Dec 11, 2013 at 1:22 PM, Krzysztof Uchronski wrote:
> Invalid in what way?
>
> Kris
>
> On Wed, Dec 11, 2013 at 1:51 PM, Bandu wrote:
> > Hi,
> >
> > I am experiencing strange issue with Windows 8.1. (only on 8.1)
> > When driver verifier is ON, I got DriverEntry’s RegistryPath contain
> invalid
> > string value when driver verifier is turned ON.
> >
> > Is that driver verifier injecting invalid string intentionally?
> > How should I handle it?
> > Couldn’t find anything about it on DDK documentation or google.
> >
> >
> > thanks.
> >
> > –
> > Bandu
> > xxxxx@gmail.com
> > — NTDEV is sponsored by OSR Visit the list at:
> > http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> > http://www.osr.com/careers 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
>
>
>
> –
> Kris
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
Bandu
xxxxx@gmail.com
How is you DriverEntry declared, and how does its beginning look, before you access the string?
Thank you for replying me.
NTSTATUS DriverEntry( IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING
pRegistryPath )
I put the break point that the very top of the method and check the local
variables on windbg.
pDriverObject entries are all valid and look fine.
only pRegistryPath got that issue.
Without verifier it work fine. If ‘DDI compliance testing’ get tick, and
verfier is ON in windows 8.1, I got that issue.
Verifier ON with all other OS work fine, even Windows 8.0. this issue I
face is only on Windows 8.1.
I am trying to run pass HCK test and I run into this issue.
Regards
Bandu
On Wed, Dec 11, 2013 at 2:30 PM, wrote:
> How is you DriverEntry declared, and how does its beginning look, before
> you access the string?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
Bandu
xxxxx@gmail.com
Print those in DbgPrint, instead.
Yes, DbgPrint give me the correct RegistryPath value.
Is that WinDbg bug? why it didn’t give the correct value?
On Wed, Dec 11, 2013 at 3:05 PM, wrote:
> Print those in DbgPrint, instead.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
Bandu
xxxxx@gmail.com
If it’s a non-debug (optimized) build, and RegistryPath is not used in the routine, the compiler won’t bother to save it from a register to the stack. What you get in the debugger is a random address, instead.
> Yes, DbgPrint give me the correct RegistryPath value.
Is that WinDbg bug? why it didn’t give the correct value?
It is a bug shared between the compiler and the debugger. The compiler
does not tell the debugger the actual “lifetimes” of values or where they
reside, so the debugger uses the compiler’s one-and-only opinion of where
the value might have been intended to be, or where the value may have
been, or where the value would be if only it weren’t stored in a register
at the moment. This is a significant defect in most compiler/debugger
environments, and I know of only one product that properly handled this
issue, and it wasn’t a C compiler (although there is no reason a C
compiler couldn’t do it). It just requires a much richer symbol table for
the debugger.
The fix, by the way, is not exactly trivial. But until someone at
Microsoft decides that it is important enough to fix, you have to be aware
of the fact that this bug (design flaw, really) exists.
joe
On Wed, Dec 11, 2013 at 3:05 PM, wrote:
>
>> Print those in DbgPrint, instead.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>
>
>
> –
> Bandu
> xxxxx@gmail.com
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
Thank you so much, everyone.
I will try to fix this one by using dbgPrint 
I may need some more help later.
On Thu, Dec 12, 2013 at 2:06 PM, wrote:
> > Yes, DbgPrint give me the correct RegistryPath value.
> >
> > Is that WinDbg bug? why it didn’t give the correct value?
> >
>
> It is a bug shared between the compiler and the debugger. The compiler
> does not tell the debugger the actual “lifetimes” of values or where they
> reside, so the debugger uses the compiler’s one-and-only opinion of where
> the value might have been intended to be, or where the value may have
> been, or where the value would be if only it weren’t stored in a register
> at the moment. This is a significant defect in most compiler/debugger
> environments, and I know of only one product that properly handled this
> issue, and it wasn’t a C compiler (although there is no reason a C
> compiler couldn’t do it). It just requires a much richer symbol table for
> the debugger.
>
> The fix, by the way, is not exactly trivial. But until someone at
> Microsoft decides that it is important enough to fix, you have to be aware
> of the fact that this bug (design flaw, really) exists.
> joe
>
> >
> > On Wed, Dec 11, 2013 at 3:05 PM, wrote:
> >
> >> Print those in DbgPrint, instead.
> >>
> >> —
> >> NTDEV is sponsored by OSR
> >>
> >> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >>
> >> OSR is HIRING!! See http://www.osr.com/careers
> >>
> >> 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
> >>
> >
> >
> >
> > –
> > Bandu
> > xxxxx@gmail.com
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > 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
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
Bandu
xxxxx@gmail.com
You will also see this behavior on the debug build of the code if you’re
broken in before the construction of the EBP frame (x86) or homing of the
register passed parameters (x64). Generally to get the correct values you
have to single step once. For example:
1: kd> u @rip l2
OsrDmk!DmkShadowDispatch
fffff8800e0c3430 mov qword ptr [rsp+10h],rdx fffff8800e0c3435 mov qword ptr [rsp+8],rcx
1: kd> dv
DeviceObject = 0x0000000000000000 Irp = 0xfffff980092c0fb0
1: kd> p
OsrDmk!DmkShadowDispatch+0xe:
fffff8800e0c343e call OsrDmk!KeGetCurrentIrql (fffff8800e0620a0)
1: kd> dv
DeviceObject = 0xfffffa801006c780 Irp = 0xfffff980092c0ca0
-scott
OSR
“Bandu” wrote in message news:xxxxx@ntdev…
Thank you so much, everyone.
I will try to fix this one by using dbgPrint
I may need some more help later.
On Thu, Dec 12, 2013 at 2:06 PM, wrote:
> Yes, DbgPrint give me the correct RegistryPath value.
>
> Is that WinDbg bug? why it didn’t give the correct value?
>
It is a bug shared between the compiler and the debugger. The compiler
does not tell the debugger the actual “lifetimes” of values or where they
reside, so the debugger uses the compiler’s one-and-only opinion of where
the value might have been intended to be, or where the value may have
been, or where the value would be if only it weren’t stored in a register
at the moment. This is a significant defect in most compiler/debugger
environments, and I know of only one product that properly handled this
issue, and it wasn’t a C compiler (although there is no reason a C
compiler couldn’t do it). It just requires a much richer symbol table for
the debugger.
The fix, by the way, is not exactly trivial. But until someone at
Microsoft decides that it is important enough to fix, you have to be aware
of the fact that this bug (design flaw, really) exists.
joe
>
> On Wed, Dec 11, 2013 at 3:05 PM, wrote:
>
>> Print those in DbgPrint, instead.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>
>
>
> –
> Bandu
> xxxxx@gmail.com
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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
–
Bandu
xxxxx@gmail.com
Variable locations and lifetimes should be precisely tracked for the debugger (even in optimized builds) if you build with the Win8 WDK or newer and use the Win8 debuggers or newer.
Note that variables may not be accessible after they are not referenced by code even with optimized debugging available, as the backing storage may be immediately repurposed by the compiler.
From: xxxxx@flounder.commailto:xxxxx
Sent: ?12/?12/?2013 6:07
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] DriverEntry’s RegistryPath contain invalid string value when driver verifier is turned ON
> Yes, DbgPrint give me the correct RegistryPath value.
>
> Is that WinDbg bug? why it didn’t give the correct value?
>
It is a bug shared between the compiler and the debugger. The compiler
does not tell the debugger the actual “lifetimes” of values or where they
reside, so the debugger uses the compiler’s one-and-only opinion of where
the value might have been intended to be, or where the value may have
been, or where the value would be if only it weren’t stored in a register
at the moment. This is a significant defect in most compiler/debugger
environments, and I know of only one product that properly handled this
issue, and it wasn’t a C compiler (although there is no reason a C
compiler couldn’t do it). It just requires a much richer symbol table for
the debugger.
The fix, by the way, is not exactly trivial. But until someone at
Microsoft decides that it is important enough to fix, you have to be aware
of the fact that this bug (design flaw, really) exists.
joe
>
> On Wed, Dec 11, 2013 at 3:05 PM, wrote:
>
>> Print those in DbgPrint, instead.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>
>
>
> –
> Bandu
> xxxxx@gmail.com
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
—
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
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</mailto:xxxxx></mailto:xxxxx>
>Variable locations and lifetimes should be precisely tracked for the debugger
(even in optimized builds) if you build with the Win8 WDK or newer and use the
Win8 debuggers or newer.
Is the debugger able to pull the local variables from higher locations of the call stack, in an optimized build?
Bandu wrote:
Thank you so much, everyone.
I will try to fix this one by using dbgPrint
However, there is a general rule to be learned here.
The debugger does the best that it can. It doesn’t always succeed.
When the debugger shows you a value that doesn’t make sense, your FIRST
job is to double-check it manually. You can go find the values
yourself. Only then should you go reporting a bug.
Those of us who have been around for a very long time know how magical
and delicate the debugger’s functioning is. Put another way, “trust,
but verify”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks, Tim.
Don’t know about others, for me, everytime when new OS with new HCK version
releases really give headaches, when BSOD.
On Thu, Dec 12, 2013 at 7:30 PM, Tim Roberts wrote:
> Bandu wrote:
> > Thank you so much, everyone.
> > I will try to fix this one by using dbgPrint
>
> However, there is a general rule to be learned here.
>
> The debugger does the best that it can. It doesn’t always succeed.
> When the debugger shows you a value that doesn’t make sense, your FIRST
> job is to double-check it manually. You can go find the values
> yourself. Only then should you go reporting a bug.
>
> Those of us who have been around for a very long time know how magical
> and delicate the debugger’s functioning is. Put another way, “trust,
> but verify”.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
–
Bandu
xxxxx@gmail.com