Nearly every day, software updates of some kind roll out for our systems. From operating systems to antivirus software, to cloud services, to hardware devices, virtually none of the technology we use is static. And with these updates come side effects and problems that sometimes take a while to get fixed.
I recently found an interesting bug that hasn’t gotten a lot of attention when I purchased a Lexmark multi-function printer. As part of the installation process, I went online to download the latest printer driver. (I always recommend going to a vendor website to grab the latest drivers because, after all, the latest software should have the latest fixes, right?) I was able to set up the printer to print, scan, and electronically fax and figured I was done for the day.
That’s when the fun started.
I regularly connect with various computers using Remote Desktop. Normally, it’s rock solid with zero issues. At least, it was rock solid before I got my new printer. Suddenly, after I set up the printer, my remote connection began to drop — without even an error message to give me some idea what had gone wrong.
This points to the first rule of debugging bugs: Think back to when everything worked and figure out what you changed. I knew something in the printer driver I’d installed was a likely culprit, but how could I confirm this? Typically, when computer systems stop working, there’s an event log somewhere that points to the problem. (Generally speaking, app crashes show up in the applications event log. But sometimes an application uses a special subdirectory to track and report errors.)
For Windows, you can access the Event Viewer by clicking on search and typing in “event viewer” to launch it. Just expand the section for Windows Logs and look in the application log file.
If you have ever looked at the Event Viewer you know these logs can either be extremely helpful or extremely confusing. Many of the events can be ignored. But every now and then you will find one that helps get to the root of your problem. With my Remote Desktop problem, I was hoping to find a clue in the event log — and indeed, I found one. I discovered an error indicating a faulting application each time I tried to launch a remote session.
Now comes the next fun part: Sometimes the application you’re using isn’t called the same thing in the event logs. Often they specifically use executable names, so you have to know the application’s “software name” rather than what you know it by. In this case, Remote Desktop has an executable name of mstsc.exe, which stands for Microsoft Terminal Service Client.
Here’s what the error looks like:
Faulting application name: mstsc.exe, version: 10.0.19041.2075, time stamp: 0x63f96292Faulting module name: LMFX1N4Z.DLL, version: 0.0.1.0, time stamp: 0x61b8cf09Exception code: 0xc0000005Fault offset: 0x0000000000038ac3Faulting process id: 0x2b30Faulting application start time: 0x01d948e5ef27f462Faulting application path: C:\WINDOWS\system32\mstsc.exeFaulting module path: C:\WINDOWS\system32\spool\DRIVERS\x64\3\LMFX1N4Z.DLLReport Id: 5b058189-0b5a-4284-a62d-c583bbe5a7daFaulting package full name: Faulting package-relative application ID:
Included in that event is the clue I needed. The event crash pointed to a driver, LMFX1N4Z.DLL, which is a Lexmark driver. Searching online, I found another computer user facing a similar issue, but with a virtual machine, not a remote desktop client. Clearly printer sharing or remote printing doesn’t like the LMFX1N4Z.dll driver. I guessed that the underlying issue involved the fax driver I happened to install. After uninstalling it, sure enough, my remote desktop again became functional. Basically, instead of trying to get Lexmark to fix an issue that’s been around for a while, I decided the best option was to remove only a piece of the printer software while keeping the features I needed.
What if I hadn’t found the root cause? Sometimes you can find a workaround. For Remote Desktop, Microsoft also ships a modern remote desktop app via the Microsoft store. If that also failed, I could have looked for alternative tools. Sometimes when a bug impacts you, that’s the only way to work around a problem until a fix is released.
Often, diagnosing a misbehaving system starts with determining whether others are experiencing the same issues. After I apply updates, I check online in several locations to confirm whether any bugs I experience are unique to me or affecting others. I start by visiting the Windows release health dashboard to review any known issues. Next, I visit Reddit’s Windows 10 and Windows 11 forums or the Askwoody forums for reports on any unusual issues.
Recently, an problem arose that prevented server administrators from installing one of this month’s updates. It turned out the root cause was a bug by Microsoft where a certain specific Windows server sku (Essentials) was improperly blocked from receiving updates. Another poster thought an issue with Windows 2012 R2 dataserver might be similar, and in reviewing the log files found that a servicing stack update was missing.
Bugs occur all the time. And not all of them are a result of poor patching by Microsoft. Often, it’s simply the introduction of something new that triggers a bug. So, always remember to ask yourself: What changed? Is there a log file? Are others seeing the same issue I am?
Answering these basic questions will help you get a bug free system.