R
rtischer8277
Guest
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
Continue reading...
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
Continue reading...