Debugging a native dll using rundll32.exe , fail to load symbols

Question

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?

Answer 1

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:

1. Debugger is not present in a process it has allegedly launched.
2. When manually attached, symbols were not loaded.
3. When hitting "Break All" process apeared to be deadloack.

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.

Answer 2

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.