Updated: December 31, 2022
The first rule of using a Windows machine is never to check the Event Viewer for errors unless you have an actual problem. The reason is, you will almost definitely find some errors in the logs. And if you're a diligent techie, you will start fretting, and perhaps even try to fix whatever problem makes the errors crop in the first place. Except, more often than not, you will waste time trying to outsmart Windows' own weirdness. But sometimes, you really will have a problem, and you will need to look at the logs.
What I encountered is as follows. I have two Windows boxen with some network shares defined to and fro. One day, on one of the machines, I saw that the file explorer window, pointing to a share on the other system looked empty - upon refresh, the correct data in the remote folder was displayed. But it did look like there had been some sort of disruption in network traffic, which probably resulted in the folder view reset. I opened the Event Viewer and found the following error: Initialization failed because the driver device could not be created. Use the string "[STRING]" to identify the interface for which initialization failed. It represents the MAC address of the failed interface or ... Hm, weird. An investigation ensues.
Problem in more detail
The full error message is as follows:
Initialization failed because the driver device could not be created. Use the string "[STRING]" to identify the interface for which initialization failed. It represents the MAC address of the failed interface or the Globally Unique Interface Identifier (GUID) if NetBT was unable to map from GUID to MAC address. If neither the MAC address nor the GUID were available, the string represents a cluster device name.
Ignoring the obvious spelling glitches - capitalization and double spaces where unnecessary, there were two instances of this error shown, both with a different [STRING] shown. Now, apart from the share view reset mentioned earlier, I couldn't really find anything wrong with the system that had exhibited the error, or correlate these messages to any odd system behavior at the specified timestamp. Finally, the Event Viewer error felt rather generic, and initially I wasn't quite sure what to do with it.
So I did the next "sensible" thing - I searched for the Event ID online.
Predictably, there were dozens of similar reports around, and EVERY single one of them had its own problem manifestation. For a lot of people, the error was accompanied with a BSOD, which my system hadn't exhibited. Some people talked about hardware problems, but as randomly as one can imagine for any Event ID search. Nothing to narrow the scope of my conundrum down.
This meant replaying my own actions around the time of the Event ID log, to see if I could understand what happened.
Soul search & solution
That particular evening, I did the following things:
- Checked email to see who hates me today.
- Connected to VPN to do some regional/latency testing for Web stuffs.
- Played on Steam, to remove all those fine passive-aggressive toxins accumulated during the day.
And then, I realized that using the VPN might actually correlate to the error at hand.
As it happens, I connected to the VPN at 20:59, about 30 seconds before the two errors showed up in the log. The VPN client is configured to forbid local network traffic while connected. So it stands to reason that if the Windows machine tried to "refresh" the shares at the time the VPN was connected, access and resolution of the NetBT (NetBIOS) session endpoints could fail, leading to the cryptic message we've seen earlier.
With this in mind, I redid the test with three different VPN providers. After a while, I was able to replicate the error in all three cases, provided the local network traffic block option was configured and active. This means the error is actually not really an error but intended behavior that Windows cannot correctly interpret. But on its own, there is no harm and no ill consequences, unless you're in a middle of a data stream/copy operation across the network nodes that might be interrupted when the VPN is activated.
I really hate weird messages in the Windows Event Viewer, and I dread finding them, because I know my OCD demons will demand some immediate Sherlock Holmes action, often resulting in a spectacular waste of time. But innocuous errors are better than serious ones, like say hardware failures, amirite. In this particular case, Windows sure didn't help, as the error may lead one to a wrong conclusion.
My message here is as follows. If you encounter a NetBT error, focus on the network stack. Yes, technically, you may have a setup issue, your router may be faulty, your Ethernet cable may be faulty, your network connection may be unstable, and whatnot. But it is also possible that you use a VPN service that blocks local network traffic, so when it's active, it will prevent Windows systems from accessing network shares, which can lead to the NetBT error we saw today. There isn't a real solution here per se, except to understand what may cause the issue, and then, how to elegantly work around it. And we're done.