Although, as I said before, I can’t talk specifically about what I’m working on in Windows for the time being, there are some general things I can say. The main thing I’m doing right now is some investigations around the diagnostic API surface of Windows. By “diagnostic,” I mean any information that Windows may possess regarding the internal state of the system at any particular moment that might be useful for understanding what’s going on. This is a pretty wide-ranging definition, covering everything from the current state of a thread up to the current state of the operating system itself.
The thing is, Windows contains an enormous amount of information about the state of things at any particular moment, but getting to that information can often be difficult or impossible. For example, a lot of components in Windows expose Event Tracing for Windows (ETW) data which can be used to look at what’s going on inside that component. The problem is that you have to know: a) which of the 100s of components that expose ETW events you should be looking at, b) which events that component surfaces you should be looking at, and c) what they mean. And usually there’s little or no documentation for any of it. In other cases, there isn’t even ETW events available–the data is just locked up in the internals of the system (unless Mark Russinovich has found it, of course).
The question I’m looking at is whether there are things that we could do to make Windows diagnostic information more available to developers (who could then use it to better understand their applications, or to build better tools for developers). I have no answers as of yet and, of course, nothing may come of this, but there you are. If you happen to be a Windows developer and are interested seeing some aspect of Windows diagnostics become more available to you, drop me a line in the contact form, I’d love to hear from you!
You should also follow me on Twitter here.