How can I analyze a performance issue that happens before or during the logon process?
Using Process Monitor
Process Monitor is a tool that will collect file system, registry and network events for all running processes. The collected events can then be analyzed to determine how a system (or an application) is behaving internally in certain situations.
In this case, we want to utilize the tool to determine which events during the boot process took a long time to complete.
xperf is a performance analysis tool from the Windows Performance Toolkit. Using it and being able to analyze the collected data can be a challenge. Nevertheless, we'll see how to collect the required data and how to view relevant sections of it.
Please note that the Windows Assessment and Deployment Kit (ADK), which is required for this, only works on Windows 7 and upwards.
After you've opened the trace, you can already see possible indications of your problem being bound to hardware. A quick look at the Computation, Storage and Memory overviews in the Graph Explorer would show peaks which should be further analyzed.
For demonstration purposes, let's have a look at the Utilization By Process graph. To display the content, simply double-click the graph to add it to the Analysis view.
Note that none of the graphs display any concerning peaks. The blue peaks at the start belong to the System process and are expected to happen at this time.
The other peaks in the CPU Usage graph might be better viewed in context. So, let's add another graph to the Analysis view. The graph we're looking for is the Boot Phases graph, which is located in the System Activity section.
In the screenshot above, I also added Generic Events graph at the bottom to provide additional context. However, what should be noted here is the fact that the first visible peak in CPU usage was caused by the Avast service. We already noticed in the Process Monitor analysis that this process was one of the processes that took up a large portion of time in the boot process.
What we also see here, now that we can see it in the context of the boot phases, is that the peak happened after the Winlogon Init phase (and even in the Post Boot phase which happens when you can already see the desktop). So it could be considered unlikely that this process is actually causing us a problem in the phase before we see the desktop.
What we would be looking for are events that happen in or around the Winlogon Init phase. To make that easier, you can select the phase in the Boot Phases graph. This will highlight all entries in all graphs that happened in that phase.
A graph to take a better look at, is certainly the Services graph, as most of them are started during the Winlogon Init phase.
As I said in the introduction, analyzing this data can be complicated, unless the problem jumps right at you once you open the trace. However, this is definitely the right tool to analyze the issue. Depending on the situation, you might even want to collect stack traces with it to drill even deeper. This process is far outside the scope of this post though.