New in February 2019

One of the things that annoys me about Microsoft’s support for those of us who manage computers, even if just our own (not that Microsoft regards any computer as just our own once Windows 10 is installed), is that although there’s a wealth of diagnostic information that Windows can be configured to collect and plenty enough visibility into whichever events do get collected, there’s strikingly little information published about what events might get collected.

Faced with a problem with some functionality, you may easily pick a plausibly relevant log from among the many that the Event Viewer presents as Applications and Services Logs (especially if Show Analytic and Debug Logs is checked), enable the log and view the possibly many events that got logged on the way to your problem’s next occurrence. It may work out. But there’s a sense of hit and miss to it. Even if you have picked a log that records events from the appropriate provider, is the log enabled for the most helpful selection of events that this provider can write? If among the events that have occurred you see one that works for you as a clue, then you’re good to go. Otherwise, you can’t easily know which events can be provided and might be vital clues but aren’t provided because you didn’t know which they are or how to enable them.

In an ideal world, Microsoft would document all the events that its many Windows components can ever write and problem-solvers would get from this a good sense of which events to look for. In what is instead our real world, I suspect an awful lot of diagnostic opportunity goes begging. There surely are things that can be done about this. Let the experimentation begin!

Kernel