Tag: Process Monitor

Efficient Windows troubleshooting: Identifying relevant event logs with Process Monitor

When doing troubleshooting one of the best places where you will find clues about the problem is in the Event Viewer logs. And when doing research on what is going on in the background when performing certain actions in Windows, the Event Viewer will come in handy.

The challenge with Event Viewer is that there are hundreds of log files, and how do you know which one(s) to investigate?

In this blog post you will learn:

  • How to use Process Monitor to figure out which the relevant event logs are, for instance when doing troubleshooting or figuring out what a specific action does in the background when researching solutions in Windows.

Method to find the relevant event logs

All event logs which are found in Event Viewer are basically files named <EventLog>.evtx and are located in C:\System32\Winevt\Logs. The key takeaway from this first part is the .evtx file ending.

The tool to use next is my favorite tool when it comes to troubleshooting and learning about stuff in Windows; and the tool is Process Monitor from Sysinternals (owned by Microsoft).

Process Monitor will gather thousands of rows of data within seconds, and this is where filtering comes in.

Crash course in Process Monitor

This is my standard procedure when using Process Monitor. Download Process Monitor if you do not already have it available.

  1. Start Process Monitor.
  2. Press Ctrl + E to pause recording events.
  3. Press Ctrl + X to clear out all events.

Adding the filter for identifying the event Logs

Now, to be able to identify the Event logs files that are of relevance to troubleshooting or to a specific action that you perform, using filters is the key in Process Monitor:

  1. In Process Monitor, press Ctrl + L to get to the filters.
  2. In the first drop down menu choose Path followed by contains in the next drop down and last enter .evtx
  3. Make sure Include is selected and click Add and OK.

Identify the relevant logs

Now you can prepare the troubleshooting step(s) or the action you want to perform and when you are ready for this:

  1. In Process Monitor, press Ctrl + E to start recording.
  2. As quickly as possible, now reproduce the problem or perform the action you want to know more about.
  3. Go back to Process Monitor and hit Ctrl + E to stop recording. Voila, you now have the relevant event logs to further investigate.

After you have the list above, you know exactly what event logs are being written to and you can do further analysis of these. Fire up Event Viewer – and happy hunting! 😊

Examples

Some examples when I’m using this method performing troubleshooting or researching in Windows:

  • Troubleshooting failed Store app installation.
  • How can I find what event logs are used when plugging in a FIDO2 security key so that I can add a scheduled task to trigger on a certain event to lock the machine when unplugged?
  • What log files are written to when doing a Sync with Intune?

Summary

Using Process Monitor to find the relevant event logs is a quick and efficient way to locate where to look next for more details. This applies to both troubleshooting and when researching the inner workings of Windows and figuring out what is going on in the background.

Case of “catastrophic failure” and error 0x8000ffff with Group Policy Preferences mapping printers

Mapping printers using Group Policy Preferences is a really nice feature and it is supposed to be working much better than using traditional scripting technologies. Let me tell you about an interesting day troubleshooting why printers didn’t want to map using Group Policy Preferences. In the logs it just stated “catastrophic failure” which does not sound good at all nor makes much sense.

Log Name: Application
Source: Group Policy Printers
Event ID: 4098
Description: The user 'X' preference item in the 'Y {3EE4E80F-17CB-4E56-9237-4FC8B9FA090A}' Group Policy object did not apply because it failed with error code '0x8000ffff Catastrophic failure' This error was suppressed.

Logging in as the user on another machine did not produce the same problem and the mapping of printers work fine, as did mapping the printers when logging in using an administrator account.

This got me thinking that I should try mapping a printer manually as the standard user so I did. It got me a “You do not have permission to use the selected printer” which made me turn to the classic tool Process Monitor and to start a trace. It didn’t take long to see that after filtering all logs for a result of “denied” resulted in the following line:

Operation: CreateFile
Result: ACCESS DENIED
Path: \\printserver\print$\w32x86\3\OPLO_UM.dll
Desired access: Generic Read

Note that CreateFile does not necessarily mean to create a file, it can mean “read file” as documented by Microsoft for the CreateFile function. 

So the conclusion was that after investigating with the printer department the printer share “print$” security permissions did not match the user and the user actually did not have read permissions to read the driver which is an absolute requirement for the printer to be mapped (as the print driver is actually installed when the printer is mapped).

Also one setting that affected the behavior was that one have to set “Run in logged-on user’s security context” in the Common tab of the printer mapping Properties. This is an essential part of the solution…

Case closed!