Debugging failed file handles in Windows Console application

Question

I have a console application that uses puTTY as a DLL and I need to debug the puTTY library in question.

On UNIX, I would do strace <command>.

strace ls ggg

Would print something like:

stat("ggg", 0x166b0d0)                  = -1 ENOENT (No such file or directory)

because I have no file or directory named ggg in my current directory. I need this for a windows console application.

I have searched online, downloaded the Windows SDK with debugging tools. I tried several programs, cdb seems to be the one I need.

doing cdb -o "!htrace -enable" <command> appears to be what I need but I think I am missing something, because it does not provide any hint to why the command is failing or failed file open attempts. (if <command> loads a file it "should" succeed, however, <command> wants a "sessions" name, not a file path, it then looks up a file or reg key with that session name):

CommandLine: <command>
Symbol search path is: srv*
Executable search path is:
ModLoad: 00400000 004a7000   image00400000
ModLoad: 77d00000 77e8d000   ntdll.dll
ModLoad: 77aa0000 77b70000   C:\WINDOWS\SysWOW64\KERNEL32.DLL
ModLoad: 748e0000 74ab7000   C:\WINDOWS\SysWOW64\KERNELBASE.dll
ModLoad: 779d0000 77a36000   C:\WINDOWS\SysWOW64\WS2_32.dll
ModLoad: 77b70000 77c2e000   C:\WINDOWS\SysWOW64\RPCRT4.dll
ModLoad: 74720000 74740000   C:\WINDOWS\SysWOW64\SspiCli.dll
ModLoad: 74710000 7471a000   C:\WINDOWS\SysWOW64\CRYPTBASE.dll
ModLoad: 74f00000 74f57000   C:\WINDOWS\SysWOW64\bcryptPrimitives.dll
ModLoad: 75d10000 75d53000   C:\WINDOWS\SysWOW64\sechost.dll
ModLoad: 757c0000 75838000   C:\WINDOWS\SysWOW64\ADVAPI32.dll
ModLoad: 776b0000 7776d000   C:\WINDOWS\SysWOW64\msvcrt.dll
(2f550.32120): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
eax=00000000 ebx=00000010 ecx=44ce0000 edx=00000000 esi=00249000 edi=77d06964
eip=77dadbcf esp=00cafa0c ebp=00cafa38 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!LdrInitShimEngineDynamic+0x6af:
77dadbcf cc              int     3
0:000> cdb: Reading initial command '!htrace -enable'
Handle tracing enabled.
Handle tracing information snapshot successfully taken.
0:000>

Basically, I am trying to find out where pscp.exe (puTTY scp) loads the session from on Windows, in this case - answering that question will not help, I want to know how I can track handles, from my understanding, cdb enables htrace after the program has completed or I need to type something for the command to start (unsure), I even tried to create a new process with the options from withing the debugger, still get only DLL's loaded, nothing else.

I tried logger.exe <command> and logger.exe -o <command> as stackoverflow says it is closest to strace, it lists the DLL's, just like cdb, nothing more. In windbg, I get to see 8 file handles, however, no information on file paths ...

Sorry, I am a Linux guy, so spoiled, strace does the trick with no options.

I have read:

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-handle https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/cdb-command-line-options https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-a-user-mode-process-using-cdb https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-create--create-process- (to try and launch <command> once the debugger was loaded) ... and a few more ...

Answer 1

You're currently using actual debug tools that can be quite hard to understand but ultimately provide a lot of detail. With your purpose of doing this it might be an option to use a simpler tool to get the information you need.

For Windows there are quite a few tools available known as the "sysinternals suite" that could help you out without requiring to understand all the debug output you get with the actual debug tools.

In particular the tool handle should be able to help you figure out what is using an currently open file. While the process monitor would show you a live feed of a lot of actions currently running programs do. Mainly focused on registry and file operations.

To figure out where a program is getting information from you could try to use process monitor and set it up to only show you the actions of a particular program. The tool itself has filtering options for various types of actions as well as for properties of those actions.