Prev: KeQueryInterruptTime() issue
Next: NDIS Mux sample
From: Volodymyr Shcherbyna on 31 Dec 2007 03:09
I would leave 'pool allocation failures' for every day tests, because it
gives a good chance to trace all possible branches of code that operates
with memory.

--
Volodymyr
NG tips:
http://msmvps.com/blogs/v_scherbina/pages/microsoft-newsgroups-tips.aspx

"Tim Roberts" <timr(a)probo.com> wrote in message
news:jghbn3p9s3en3kav05k7v6481f35aceri5(a)4ax.com...
> "Volodymyr Shcherbyna" <v_scherbina(a)online.mvps.org> wrote:
>>
>>P.S. I also hope that you do not verify (using verifier.exe) the driver,
>>because in some cases it may fail to load due to failures in memory
>>allocations.
>
> Only if you enable pool allocation failures, which you should not do
> except
> during an intentional test. I run with verifier enabled on my drivers
> 100%
> of the time.
> --
> Tim Roberts, timr(a)probo.com
> Providenza & Boekelheide, Inc.


From: SergeV on 10 Jan 2008 02:55
Hello, Volodymir.
Would you please kindly poke my nose a bit deeper in the way
of doing 3rd party driver debug with WinDbg.
(I did as much as I could, but seems I dont't understand something)

I do download and install WinXP pdb symbols, then
using WinDbg I add this to the Symbol File Path, and then
I select "kernel debugging/Local" mode.

Last, before plugging USB device in I have to put/set the breakpoint to
ZwLoadDriver
as you suggested. Right? Mmmm.. cannot find the right place to do this
(am I crazy?).
And (I never did this before) will I really have the Windows break?

Thank you
(and Tim, of course, for valuable comments)
Serge V.

"Volodymyr Shcherbyna" wrote
>>> Also, you can debug this driver using WinDbg (or SoftIce). Just put
>>> breakpoint to ZwLoadDriver and look how things go.
>>
>> You mean Windows checked build ?
>
> No. I mean debugging faulting driver DriverEntry routine.
>


From: Volodymyr Shcherbyna on 10 Jan 2008 07:08
Hello Serge,

When you start a debugging session, open command window, and do:

0: kd> bp ZwLoadDriver
0: kd> bp NtLoadDriver
0: kd> bl
0 e 80582dfe 0001 (0001) nt!NtLoadDriver
1 e 804ff834 0001 (0001) nt!ZwLoadDriver
0: kd> g

(bl is for listing all breakpoints, g is to let debugger continue). Then,
let the driver load, and wait untill breakpoint hit: (here comes the
beggining of the function)

nt!NtLoadDriver:
80582dfe 6a54 push 54h
80582e00 6850964d80 push offset nt!GUID_DOCK_INTERFACE+0x52c
(804d9650)
80582e05 e8667dfbff call nt!_SEH_prolog (8053ab70)
80582e0a 33f6 xor esi,esi
80582e0c 33db xor ebx,ebx

Make sure this is a correct driver, which is going to be loaded. ESP + 4 is
the pointer to UNICODE_STRING structure, so make the dump of stack:

0: kd> dd (ESP + 4)
f8c1ad60 009ff7b4 009ff7c4 7c90eb94 badb0d00
f8c1ad70 009ff7a4 00000000 00000000 00000000
f8c1ad80 00000000 00000000 00000000 00000000
f8c1ad90 00000000 00000000 00000023 00000023
f8c1ada0 7c90eb94 009ffc74 00000000 00000001
f8c1adb0 ffffffff 0000003b 0101a024 0071a920
f8c1adc0 000ccd10 009ff7c4 00000000 7c90eb94
f8c1add0 0000001b 00000296 009ff79c 00000023

ESP + 4 contains 009ff7b4, output the UNICODE_STRING structure:

0: kd> !ustr 009ff7b4
String(116,118) at 009ff7b4:
\Registry\Machine\System\CurrentControlSet\Services\vPCdrv

Then, analyze the code of NtLoadDriver. You will notice, that it uses a
system thread to execute the driver loading routine. That is, NtLoadDriver
invokes ExQueueWorkItem at the end. So you will need to set up a breakpoint
in it:

1: kd> bp ExQueueWorkItem
1 e 805375b4 0001 (0001) nt!ExQueueWorkItem

Wait untill the breakpoint hit. Analyze the params of function in
documentation. It's declared as

VOID
ExQueueWorkItem(
IN PWORK_QUEUE_ITEM WorkItem,
IN WORK_QUEUE_TYPE QueueType
);

So, ESP + 4 is a pointer to WorkItem structure, so let's get it:

1: kd> dd ESP + 4
f8c1ace0 f8c1acf4 00000001 f8c1ad64 009ff7a8
f8c1acf0 80582dfe 00000000 00000000 80580134
f8c1ad00 f8c1acf4 00040000 00000000 f8c1ad0c
f8c1ad10 f8c1ad0c 00000000 f8c1ad28 009ff7a4
f8c1ad20 00760074 000ccd10 00760074 e160cf20
f8c1ad30 00000030 8194d020 009ff701 e160cf20
f8c1ad40 f8c1ace8 00000000 ffffffff 80538aa0
f8c1ad50 804d9650 ffffffff f8c1ad64 8054060c

As it seems, the f8c1acf4 is a pointer to structure, take a look at
definition of structure:

typedef struct _WORK_QUEUE_ITEM {
LIST_ENTRY List;
PWORKER_THREAD_ROUTINE WorkerRoutine;
PVOID Parameter;
} WORK_QUEUE_ITEM, *PWORK_QUEUE_ITEM;

First item: List is an 8 bytes long, so we need to get the pointer of a
worker function which is stored at f8c1acf4 + 8, let's take a look at this
value: 0x80580134. So, we need to put breakpoint to 80580134:

1: kd> bp 80580134

As you will see, this address actually maps into nt!IopLoadUnloadDriver:

nt!IopLoadUnloadDriver:
80580134 8bff mov edi,edi
80580136 55 push ebp
80580137 8bec mov ebp,esp
80580139 51 push ecx
8058013a 53 push ebx
8058013b 56 push esi

Continue execution of function, untill you will see the following place:

8057fb09 689ef95780 push offset nt!IopAbortRequest+0x22 (8057f99e)
8057fb0e 8d45a4 lea eax,[ebp-5Ch]
8057fb11 50 push eax
8057fb12 e82faffaff call nt!RtlAppendUnicodeToString (8052aa46)

This place constructs a string which is passed into DriverEntry, my value of
eax is f9082cf8:

1: kd> !ustr 8192a8a8
String(118,80)1: kd> !ustr f9082cf8
String(12,20) at f9082cf8: vPCdrv

'vPCdrv' is the name of a driver, which is loading. Continue execution of
function. It will take a while to step throught code which makes
initialization of image before loading, and finally,

80580060 ffb570ffffff push dword ptr [ebp-90h]
80580066 57 push edi
80580067 ff572c call dword ptr [edi+2Ch]
ds:0023:81a28e24={vPCdrv!GsDriverEntry (f8f27005)}
8058006a 3bc3 cmp eax,ebx ; cmp ret val of DriverEntry

The line :

80580067 ff572c call dword ptr [edi+2Ch]
ds:0023:81a28e24={vPCdrv!GsDriverEntry (f8f27005)}

Is the code which calls DriverEntry of driver. You can set breakpoint to
this address directly if you're under XP SP2 with all latest updates on and
continue investigation of driver's entry point.

--
Volodymyr
NG tips:
http://msmvps.com/blogs/v_scherbina/pages/microsoft-newsgroups-tips.aspx
"SergeV" <s_no_spam_v(a)a_ca.de_m.org> wrote in message
news:uY8l941UIHA.4624(a)TK2MSFTNGP03.phx.gbl...
> Hello, Volodymir.
> Would you please kindly poke my nose a bit deeper in the way
> of doing 3rd party driver debug with WinDbg.
> (I did as much as I could, but seems I dont't understand something)
>
> I do download and install WinXP pdb symbols, then
> using WinDbg I add this to the Symbol File Path, and then
> I select "kernel debugging/Local" mode.
>
> Last, before plugging USB device in I have to put/set the breakpoint to
> ZwLoadDriver
> as you suggested. Right? Mmmm.. cannot find the right place to do this
> (am I crazy?).
> And (I never did this before) will I really have the Windows break?
>
> Thank you
> (and Tim, of course, for valuable comments)
> Serge V.
>
> "Volodymyr Shcherbyna" wrote
>>>> Also, you can debug this driver using WinDbg (or SoftIce). Just put
>>>> breakpoint to ZwLoadDriver and look how things go.
>>>
>>> You mean Windows checked build ?
>>
>> No. I mean debugging faulting driver DriverEntry routine.
>>
>
>


From: SergeV on 11 Jan 2008 02:03
Great! Thank you.

"Volodymyr Shcherbyna" wrote in message
> Hello Serge,
>
> When you start a debugging session, open command window, and do:
.... ... ...
>


From: Volodymyr Shcherbyna on 11 Jan 2008 05:24
Feel free to ask questions regarding this problem

--
Volodymyr
NG tips:
http://msmvps.com/blogs/v_scherbina/pages/microsoft-newsgroups-tips.aspx
"SergeV" <s_no_spam_v(a)a_ca.de_m.org> wrote in message
news:OcCeTACVIHA.3364(a)TK2MSFTNGP03.phx.gbl...
> Great! Thank you.
>
> "Volodymyr Shcherbyna" wrote in message
>> Hello Serge,
>>
>> When you start a debugging session, open command window, and do:
> ... ... ...
>>
>
>


First  |  Prev  | 
Pages: 1 2
Prev: KeQueryInterruptTime() issue
Next: NDIS Mux sample