More \Device\Afd goodness

For a while now I’ve been playing around with the low-level access to the Windows networking stack that is provided by \Device\Afd. Recently I had a comment from a reader, Matt James, who pointed me in the direction of his work over at which does a lot more with the \Device\Afd interface than I have. It’s well worth checking out. This code includes, as reference, a set of NT Native API headers from the Process Hacker project, which in itself is interesting stuff, but Matt’s code goes far beyond my megre investigations and provides enough information to produce a full featured network API that appears to be able to everything you might need through the \Device\Afd interface.

Asynchronous Events: Bug in OOB data handling

There’s a bug in the TCP OOB (out of band) data handling code in all versions of The Server Framework from 6.6 through to 7.4. This issue manifests as a purecall during socket destruction and is due to a race condition during the release of the last two references held on a socket. If you don’t use OOB then a simple work around is to comment out the following in TAsyncSocket.

Debugging yourself...

Recently I spent quite a long time debugging a heap corruption bug. When I eventually found the issue, it was such a classic buffer overrun bug that it was actually quite laughable how long it had taken to track it down. It was just SO obvious that I immediately spotted it as soon as I looked at the code. The problem was that it took me so long to actually look at this piece of code.

The US government's view on memory safe code is not the whole story

There’s a lot of noise about how “Joe Biden’s government wants you to move away from using C++”. This is as a result of the US government releasing a report, Back to the building blocks: A path toward secure and measurable software which suggests: Uncle Sam says "no!" “Memory safety vulnerabilities are a class of vulnerability affecting how memory can be accessed, written, allocated, or deallocated in unintended ways. Experts have identified a few programming languages that both lack traits associated with memory safety and also have high proliferation across critical systems, such as C and C++.

MiniDumpWriteDump now mostly useless for in process use

I’ve been using the MiniDumpWriteDump() API from DbgHelp.dll for 20 years or so. It has proven to be a useful diagnostic tool, and I use it in all manner of places, including many where others may simply use an assert(). It’s a heavy-weight debugging tool, but it has proved useful over the years; rather than just throwing an exception because things that shouldn’t happen have happened, I often also generate a dump file so that I can get far more data than you could ever log or report in another way.

Old and cranky me from 20 years ago

Back in 2004 I wrote this, I wonder why I used to make some people unhappy… I’m starting to believe that, at 37, I must now be old and cranky because to be quite honest with you; if you’re not writing code in such a way that you define concepts and abstractions in such a way that the actual main line business logic code that you write is clear and easy to understand then you’re just not doing it right.

Adventures with \Device\Afd - a simple server

The only difference between a client and a server is the way in which the connection is established. For a client, you create a socket and call “connect” on it. For a server, we have a socket that is “listening” for connections “accepts” new incoming connections and returns a socket that is then indistinguishable from a client connection. In the past, I’ve created bad abstractions at this point. A socket connection and a listening socket are both represented by the operating system API as the same type, and the only differences are the calls that you make on the type.

Adventures with \Device\Afd - a simple client

Now that I have a reasonably easy to use event-driven socket class I can start to use it. The first thing to build is a simple client. This will connect to a server and expect that server to echo anything that is sent to it. The client will send data and read it back and compare it with what it sent. A simple, single-threaded, client Last time, I put together a tcp_socket object that made it easier to work with the \Device\Afd interface that I’ve been playing with.

Adventures with \Device\Afd - test driven design

I’ve been investigating the ‘sparsely documented’ \Device\Afd interface that lies below the Winsock2 layer. Today I use a test-driven method for building some code to make using this API a little easier. Using the API In my previous posts on the \Device\Afd interface I focused on exploring and understanding the API itself. Since it’s ‘sparsely documented’ I used unit tests to explore and record my findings. This has left me with some code that is easy to come back to and pick up, which is lucky since it’s been quite a while since I last had some time to tinker with it.