what print function and its “include header file” can be used?
And by this function, where could I see the print, from windbg at Host PC or from debugview.exe at the target PC?
About setting breakpoint with windbg
I have setup the NET debugging environment, and host and target’s connection is OK.
Any special tips for set breakpoint for DLL?
And I try to add code like following in DllMain()
__asm
{
int 3;
}
I am not sure if this could work, because I have not see any difference between I add or not add this code.
it is always “code not found, breakpoint not set”.
After “.reload /f”, still this case:
and:
windbg print:
3: kd> .reload /f
Connected to Windows 8 9200 x86 compatible target at (Wed Nov 26 11:05:27.213 2014 (UTC + 8:00)), ptr64 FALSE
Loading Kernel Symbols
…*** ERROR: Symbol file could not be found. Defaulted to export symbols for ndis.sys -
…*** ERROR: Module load completed but symbols could not be loaded for ddkmdldr.sys
…*** ERROR: Module load completed but symbols could not be loaded for dlkmdldr.sys
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
…*** ERROR: Module load completed but symbols could not be loaded for ddkmd.sys
…*** ERROR: Module load completed but symbols could not be loaded for dlkmd.sys
…
…*** ERROR: Symbol file could not be found. Defaulted to export symbols for igdkmd32.sys -
…*** ERROR: Module load completed but symbols could not be loaded for HECI.sys
…*** ERROR: Symbol file could not be found. Defaulted to export symbols for drmk.sys -
…
…*** ERROR: Module load completed but symbols could not be loaded for peauth.sys
.*** ERROR: Module load completed but symbols could not be loaded for secdrv.SYS
…*** ERROR: Module load completed but symbols could not be loaded for Dbgv.sys
.*** ERROR: Module load completed but symbols could not be loaded for MpKsl7c342aae.sys
…
Loading User Symbols
.*** ERROR: Module load completed but symbols could not be loaded for ddmgr.exe
…
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
You should never use a breakpoint like this because that would result in an unhandled exception if no debugger is present. The system would then crash (kernel mode), or the process would crash (user mode).
In user user mode ,use this code:
if(IsDebuggerPresent()){
// A debugger is attached
OutputDebugString(TEXT(“DllMain: breaking into debugger\n”));
DebugBreak();
}
In kernel mode, use this code:
if (KD_DEBUGGER_NOT_PRESENT == FALSE){
// A kernel debugger is active.
DbgPrint(“DllMain: breaking into debugger\n”);
DbgBreakPoint();
}
I am not sure whether it is kernel or user mode dll.
For God’s sake, how can you possibly not know that?? Are you going to be calling this DLL from an application? Or are you going to be calling it from a kernel driver?
If you are going to be calling it from an application, then of course you can’t include <wdm.h> or call any kernel APIs, nor can you debug it using a KERNEL debugger connection. You can still use WinDbg, but you will run WinDbg on the machine with the DLL, and you will have to debug the process that calls the DLL. – Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.</wdm.h>
> 1. what print function and its “include header file” can be used?
It’s up to you to design the UI (including printouts) for the DLL.
There are lots of options:
classic Windows Application event log
ETW (which also gives you the new-style Windows event logs)
fprintf() to a text file
calling the caller-provided print callback
show a GUI dialog from the DLL (be sure you can properly specify the parent window for it, the parent usually belongs to the caller)
just printf() to stdout
Option 6, even though it is a simplest one, requires the DLL loading process to have stdout, which is not always the case (and usually not the case) for a GUI app.
With EXE, there is no such problem, since you can develop it to be command-line-oriented from the very beginning. You can’t do this with a DLL, since you don’t know what processes will be loading it.
__asm
{
int 3;
}
I am not sure if this could work
It will.
Though DebugBreak will provide 1 more level on a call stack. More convenient usually.
[quote]
If you are going to be calling it from an application, then of course you can?t
include <wdm.h> or call any kernel APIs, nor can you debug it using a KERNEL debugger connection. You can still use WinDbg, but you will run WinDbg on the machine with the DLL, and you will have to debug the process that calls the DLL.
[quote]
Currently, I am using Windbg with NET, it could debug the DLL on the target Win8 32 system.
> I am not sure whether it is kernel or user mode dll. But at DllMain, I can’t use KdPrint,
> even I include the “wdm.h” header file. So I think it is a user mode dll.
Where is Mr.Aseltine - after all, this one is an exceptional “masterpiece” even by Wesley’s standards…
Why not? DbgPrintEx, vDbgPrintExWithPrefix are exported by ntdll and can
be called from user mode. I use this sometimes (without wdm.h, of course)