Shellcode executing warning about kdu HOT 4 CLOSED

Your log is ok. The Mark Russinovich tool is bugged. Select everything except "Log Boot" and try again with restarting DbgView. If it doesn't work use DummyDrv2 example driver - during work it creates a named device \Device\TDLD, it can be verified with something like WinObjEx64.

from kdu.

Your log is ok. The Mark Russinovich tool is bugged. Select everything except "Log Boot" and try again with restarting DbgView. If it doesn't work use DummyDrv2 example driver - during work it creates a named device \Device\TDLD, it can be verified with something like WinObjEx64.

Now looks it created new device, named TDLD.

dbgviewer worked before and output driver debug logs, strange because dbgviewer crash if I select all modes, with "Capture Events", it looks broken. KDU looks very userful for working with any custom drivers without test-sign mode. Apparently everything works, but I need ways to debug this. Can you recommend anything that will help me debug my drivers, so that first I can at least see the result of initializing my driver? Thanks in advance.

from kdu.

DbgView often crashes when you enable logging and run something from inside of Visual Studio (debug or release, doesn't matter).

If you want DbgView style and don't want to use WinDbg you can follow the above method and use named objects, for example named events. Also AFAIR there are similar to DbgView tools available, some ARK's maybe. Not sure if they use DbgSetDebugPrintCallback like DbgView does but you can try.

from kdu.

DbgView often crashes when you enable logging and run something from inside of Visual Studio (debug or release, doesn't matter).

If you want DbgView style and don't want to use WinDbg you can follow the above method and use named objects, for example named events. Also AFAIR there are similar to DbgView tools available, some ARK's maybe. Not sure if they use DbgSetDebugPrintCallback like DbgView does but you can try.

Thanks for advice. =)

from kdu.