WinDBG set breakpoint problem

I’ve just faced a problem. My driver works in pair with user mode app. I
have two different classes with the same name (class CRegisteredClient) one
for kernel mode one for user mode. Source files are also have the same name
(client.h) and are in different folders. Source file path is setup to point
to both of those directories. When I try to put a breakpoint in user mode
app (say [UM]CRegisteredClient::_GetEvents), WinDBG confuses and tries to
put breakpoint in another source file ([KM]CRegisteredClient::_GetEvents
which does not exist at all).

Is there any workaround? I use WinDBG v6.0.17.0.

-htfv

I wanted to add that when I try to put breakpoint in
[UM]CRegisteredClient::_GetEvents, WinDBG tries to put it in
[KM]CRegisteredClient::GetEvents (which really exists). Writing location
manually (like Vba32prx!CRegisteredClient::_GetEvents) does not help.

-htfv

----- Original Message -----
From: “Alexey Logachyov”
To: “Kernel Debugging Interest List”
Sent: Wednesday, August 07, 2002 12:09 PM
Subject: [windbg] WinDBG set breakpoint problem

> I’ve just faced a problem. My driver works in pair with user mode app. I
> have two different classes with the same name (class CRegisteredClient)
one
> for kernel mode one for user mode. Source files are also have the same
name
> (client.h) and are in different folders. Source file path is setup to
point
> to both of those directories. When I try to put a breakpoint in user mode
> app (say [UM]CRegisteredClient::_GetEvents), WinDBG confuses and tries to
> put breakpoint in another source file ([KM]CRegisteredClient::_GetEvents
> which does not exist at all).
>
> Is there any workaround? I use WinDBG v6.0.17.0.
>
> -htfv
>
>
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>

You need to do 2 things:
First if you want to set a breakpoint on UM code from KD you
need to make sure you are in the right process context. You can do this
with .process.

Second specify the module name like
“Vba32prx!CRegisteredClient::_GetEvents” If your driver & UM stuff have
the same file name minus extension (i.e. vba32prx.sys and vba32.prx.exe)
then the debugger will “rename” one of them by appending the module load
address. The “lm” command is useful to determine the new name.

But really why would you want to debug a UM app from the kernel debugger
if you could help it? Using a user mode debugger is much richer and
easier. Lucky you in that Windbg does user mode and kernel mode
debugging. Simply start your app under windbg like this “windbg -g -G
myapp.exe ” and you are good to go.

-----Original Message-----
From: Alexey Logachyov [mailto:xxxxx@vba.com.by]
Sent: Wednesday, August 07, 2002 2:18 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: WinDBG set breakpoint problem

I wanted to add that when I try to put breakpoint in
[UM]CRegisteredClient::_GetEvents, WinDBG tries to put it in
[KM]CRegisteredClient::GetEvents (which really exists). Writing location
manually (like Vba32prx!CRegisteredClient::_GetEvents) does not help.

-htfv

----- Original Message -----
From: “Alexey Logachyov”
To: “Kernel Debugging Interest List”
Sent: Wednesday, August 07, 2002 12:09 PM
Subject: [windbg] WinDBG set breakpoint problem

> I’ve just faced a problem. My driver works in pair with user mode app.

> I have two different classes with the same name (class
> CRegisteredClient)
one
> for kernel mode one for user mode. Source files are also have the same
name
> (client.h) and are in different folders. Source file path is setup to
point
> to both of those directories. When I try to put a breakpoint in user
> mode app (say [UM]CRegisteredClient::_GetEvents), WinDBG confuses and
> tries to put breakpoint in another source file
> ([KM]CRegisteredClient::_GetEvents
> which does not exist at all).
>
> Is there any workaround? I use WinDBG v6.0.17.0.
>
> -htfv
>
>
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

>But really why would you want to debug a UM app from the kernel debugger

if you could help it? Using a user mode debugger is much richer and
easier. Lucky you in that Windbg does user mode and kernel mode
debugging. Simply start your app under windbg like this “windbg -g -G
myapp.exe ” and you are good to go.
I experience some synchronization problems, so I wanted to debug both of
driver and app at once.

-htfv