Skip to main content

 none
Which (kernel) debugger should I use to help me resolve debug lowlevel windows socket calls? RRS feed

  • Question

  • Several times now my project's dev progress has been halted by not being able to debug into underlying Microsoft socket and bind functions. My first encounter was how to determine socket interface type "Since I couldn't debug bind()". My second encounter was Binding an ipv6 slaac address to windows IP Stack error 10049. And I am on my 3rd encounter now which is Unable to GetUnicastIpAddressEntry after CreateUnicastIpAddressEntry which involves low-level windows socket API calls.

    In each case, if I had the ability to debug farther down into the calls, I would have been able to solve the problem and move on. Asking StackOverflow for answers to these low-level call issues is useless, which is why I was exploring kernel-level debuggers. Especially now with the transition from ipv4 to ipv6, knowing what is going on inside socket(), bind() and listen() _impl*** functions is essential. I know how to run WinDbg Preview now. Will running WinDbg in kernel mode help me debug through these so far opaque calls? Or will I still meet "source not available" when I hit one of these calls?


    RT

    Tuesday, November 12, 2019 2:06 PM

Answers

  • You are not going to have the source, but you can get some useful information, by debugging the calls with Windbg.  First kernel error codes are not Win32 error codes, so you may get a more detailed error (since some of the Win32 codes represent a lot of kernel error codes).   Second, a lot of kernel functions are documented, so if you get a clue what the kernel function is that is failing you may find your answer.   This type of debugging is an art, and it requires some understanding of assembler code.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Tuesday, November 12, 2019 3:34 PM

All replies

  • You are not going to have the source, but you can get some useful information, by debugging the calls with Windbg.  First kernel error codes are not Win32 error codes, so you may get a more detailed error (since some of the Win32 codes represent a lot of kernel error codes).   Second, a lot of kernel functions are documented, so if you get a clue what the kernel function is that is failing you may find your answer.   This type of debugging is an art, and it requires some understanding of assembler code.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Tuesday, November 12, 2019 3:34 PM
  • So be it. As a former EE, I did assembly code long ago, but today, as a full-blown app developer, I was hoping to avoid spending resources on that again. But that is exactly why I went with MFC (never left it actually) because I know I could, if I had to, dig down to the bottom if need be. And `bind()` and `listen()` in ipv6 are certainly going to require that.

    I was impressed by WinDbg Preview the 2 weeks I worked with it for both its modernized ribbon interface and its time-travel debugging. Now that I know the source code is not something I just missed, then I will gear up for debugging battle on these socket API calls.


    RT

    Wednesday, November 13, 2019 6:13 PM