Reputation: 111
I'm writing a native dll that is due to run with rundll32.exe
(that is obligated by our clients). I've using VS
's debugging properties to define:
Command: c:\windows\system32\rundll32.exe
Command Argument: $(TargetPath) , ENTRY_POINT
where ENTRY_POINT
is an exported function of my dll, that obey the rundll32.exe
interface.
This setup calls my function , but won't load any symbols and thus won't trigger any break point. I've learned that my function was called only after placing a call to MessageBox
at its entrance.
when I use my own container application (just an exe
calling Loadlibrary
, GetProcAddress
and the ENTRY_POINT
function itself) all break points are triggered, and a step-by-step debugging is possible as usual.
what can cause that behavior?
Upvotes: 3
Views: 4440
Reputation: 111
In short: All problems arose due to debugging a 32Bit
dll in a 64Bit
environment.
As can be seen from original question, and side issues mentioned in comments, I had few problems here:
The reason is as mention the dll being 32Bit
while debugger is 64Bit
. The path to rundll32.exe
interpernted as the 64Bit
version. That normally causes WOW64
to launch a sub-process of the 32Bit
version - hereby different process thus debugger not present.
Thanks all.
Upvotes: 2
Reputation: 941465
The MessageBox() gives you enough rope to troubleshoot this problem. When it displayed, use Debug + Break All to break into the debugger. Next, use Debug + Windows + Modules, locate the DLL in the list. Right-click it and select "Symbol Load Information". You get a list of all the directories where the debugger searched for your PDB file. Make sure it is present in one of them.
Fwiw, your Command Arguments setting isn't kosher. It should be "$(TargetPath)" ENTRY_POINT
. Double quotes to avoid trouble with spaces in the path name, no comma.
Upvotes: 2