search

CobaltFusion / DebugViewPP

DebugView++, collects, views, filters your application logs, and highlights information that is important to you!
Boost Software License 1.0
982 stars 144 forks source link

debugview++ fails to capture loader snaps #309

Open janwilmans opened 6 years ago

janwilmans commented 6 years ago

pingback from https://forum.sysinternals.com/using-debugview-to-see-loader-snaps_topic30967.html

I was trying to diagnose loading problems on a customer machine, used GFlags to raise 'ShowSnaps' and tried to capture the output with DebugView - with no success.

gflags /i notepad.exe +sls

ShowSnaps causes the windows loader to internally call LdrpLogDbgPrint - is this flavour of DbgPrint not captured by DebugView? It would be immensely useful if it was.

You can verify this locally: in gflags / image files / image = 'calc.exe', check ' Show Loader Snaps', then run DebugView and afterwards Calculator. Nothing appears on the log, regardless of which items you check on the 'capture' menu.

https://forum.sysinternals.com/using-debugview-to-see-loader-snaps_topic30967.html related quote?:


this is so old school. Use xperf (http://social.technet.microsoft.com/wiki/contents/articles/4847.install-the-windows-performance-toolkit-wpt.aspx) to capture the image load data (also with callstacks:

xperf -on PROC_THREAD+LOADER -stackwalk ImageLoad+ImageUnload -buffersize 1024 -MaxFile 1024 -FileMode Circular && timeout -1 && xperf -d diagImageLoad.etl

janwilmans commented 6 years ago

retest with 424dd4318685aea5d8a9084a2724dc59ff38561b

janwilmans commented 6 years ago

also test / check out https://github.com/smourier/TraceSpy http://alter.org.ua/soft/win/dbgdump/#download

exoosh commented 7 months ago

Getting the same behavior with Sysinternals' DbgView, however (the version from 2019, which is the most recent as of this writing).

When debugging something inside VS, however, loader snaps are showing up. Possible that they are actually some sort of ETW records rather than landing in the debug buffer? It'd be conceivable that VS merely lumps them together.

Hmm, so internally the function LdrpLogDbgPrint (ULONG __stdcall LdrpLogDbgPrint(PCCH Filename, ULONG Line, PCCH Function, ULONG InfoLevelIndex, PCCH Format, va_list ap)) calls vDbgPrintExWithPrefixInternal which is the va_list version of ULONG DbgPrintEx(ULONG ComponentId, ULONG Level, PCSTR Format, ...) (from ntdll.dll). It passes a component ID of 0x55. I reckon the way to filter for it is to somehow include that component ID when capturing.

At least I can confirm that it is debug output and not ETW output.