It’s that Co-installer again …
How does one do remote debugging on it?
In setting up the Project settings I set the executable to
E:\winnt\system32\mmc.exe
Working directory is D:\Winnt\system32
No arguments
Remote directory is set to D:\winnt\system32\mmc.exe.
(Note that E: is the target driver on the target machine, and D: is that
drive as seen from the target.)
From that point everything works. MMC comes up and I enter the device
manager and select my driver. However, when I select the property page on
the device property sheet for my device, mmc throws an Access Denied
exception, and none of the breakpoints I set in the co-installer (DllMain
included) trigger.
Curious’r and curious’r said Alice.
Gary
Does any one else have the same problem I do? You beat your head against the
wall trying to figure something out, finally give up and post a question to
the list. As soon as you send it you go try it one more time … and figure
it out.
In this case it comes under the category of RTFM and age. Us old guys forget
things. I’ve remotely debugged DLL’s in the past, but forgot. So
after making the original post I RTFM, and low and behold, the light dawned,
the birds sang, and there was joy in Mudville! It seems there is a drop down
combo box on the Debug tab of Project Settings, and one of the two
selections is Additional DLLs. Oh yeah … set the DLLs here … works like
a charm.
Gary
(still mumbling but at least no longer drooling)
I’ve been struggling myself with this for the past couple of weeks.
Here’s what I’ve been doing. It works, but it’s not terribly
convenient:
* Plug in new device
* Start windbg
* Attach to the rundll32.exe process via F6 in windbg. Note there may
be a few of these guys running. You generally want the newest one. I
also have manager running so I can see which rundll32 is the newest one
(and the one using the CPU).
* Alt-tab back to the h/w wizard, if you attached to the right
rundll32.exe then the h/w wizard won’t be able to paint. If the h/w
wizard is able to paint, then you got the wrong rundll32.exe. Go back
to the previous step.
* Set a breakpoint in your coinstaller dll (bp w/o .dll>!) or add a DebugBreak() in your source.
* Hit go in windbg
* Proceed with installing your device and Windbg should catch the
breakpoint.
If you have a device that you can’t hot plug, then ESC out of the first
hardware wizard that appears after you first log in, and then start
device manager, attach the debugger to the right rundll32, and install
your driver.
Has anyone else found an easier way to debug a co-installer?
–Sandy
-----Original Message-----
From: Gary Little [mailto:xxxxx@delphieng.com]
Sent: Wednesday, November 15, 2000 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] Debugging a Co-installer …
Does any one else have the same problem I do? You beat your head against
the
wall trying to figure something out, finally give up and post a question
to
the list. As soon as you send it you go try it one more time … and
figure
it out.
In this case it comes under the category of RTFM and age. Us old guys
forget
things. I’ve remotely debugged DLL’s in the past, but forgot. So
after making the original post I RTFM, and low and behold, the light
dawned,
the birds sang, and there was joy in Mudville! It seems there is a drop
down
combo box on the Debug tab of Project Settings, and one of the two
selections is Additional DLLs. Oh yeah … set the DLLs here … works
like
a charm.
Gary
(still mumbling but at least no longer drooling)
—
You are currently subscribed to ntdev as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Sandy,
In your Project Settings … set the executable to mmc.exe, with Additional
DLL to your coinstaller.
Gary
-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@Exchange.Microsoft.com]
Sent: Wednesday, November 15, 2000 3:18 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Debugging a Co-installer …
I’ve been struggling myself with this for the past couple of weeks. Here’s
what I’ve been doing. It works, but it’s not terribly convenient:
* Plug in new device
* Start windbg
* Attach to the rundll32.exe process via F6 in windbg. Note there may be a
few of these guys running. You generally want the newest one. I also have
manager running so I can see which rundll32 is the newest one (and the one
using the CPU).
* Alt-tab back to the h/w wizard, if you attached to the right rundll32.exe
then the h/w wizard won’t be able to paint. If the h/w wizard is able to
paint, then you got the wrong rundll32.exe. Go back to the previous step.
* Set a breakpoint in your coinstaller dll (bp .dll>!) or add a DebugBreak() in your source.
* Hit go in windbg
* Proceed with installing your device and Windbg should catch the
breakpoint.
If you have a device that you can’t hot plug, then ESC out of the first
hardware wizard that appears after you first log in, and then start device
manager, attach the debugger to the right rundll32, and install your driver.
Has anyone else found an easier way to debug a co-installer?
–Sandy
-----Original Message-----
From: Gary Little [mailto:xxxxx@delphieng.com
mailto:xxxxx]
Sent: Wednesday, November 15, 2000 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] Debugging a Co-installer …
Does any one else have the same problem I do? You beat your head against the
wall trying to figure something out, finally give up and post a question to
the list. As soon as you send it you go try it one more time … and figure
it out.
In this case it comes under the category of RTFM and age. Us old guys forget
things. I’ve remotely debugged DLL’s in the past, but forgot. So
after making the original post I RTFM, and low and behold, the light dawned,
the birds sang, and there was joy in Mudville! It seems there is a drop down
combo box on the Debug tab of Project Settings, and one of the two
selections is Additional DLLs. Oh yeah … set the DLLs here … works like
a charm.
Gary
(still mumbling but at least no longer drooling)
—
You are currently subscribed to ntdev as: xxxxx@exchange.microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)</mailto:xxxxx>
RE: [ntdev] Debugging a Co-installer …>Has anyone else found an easier way
to debug a co-installer?
IIRC placing the breakpoint explicitly in the code is a standard way of
debugging such DLLs. This will trigger the MSVC debugger if it is installed.
I have done this with shell extension DLLs with great success.
Max