Showing posts with label Tracing. Show all posts
Showing posts with label Tracing. Show all posts

Friday, June 3, 2016

Outlook Troubleshooting - Enable Logging



Scenario 

There may be times when you are  troubleshooting Outlook issues, but you would like to have more information about what Outlook is doing in the background.  This is often the case when something happens in Outlook that isn’t right, but there aren’t any popup error messages.

Thursday, April 16, 2015

How to Enable Procmon Boot Logging with Script


Scenario:

In order to use Procmon to log operations on boot up, you have to go to Options and then select Enable Boot Logging. Once you have done that, you can reboot your computer, logon to your computer, launch Procmon again, and then you can save the boot log.  There may be an occasion when you want to enable it on multiple machines using a script.  This is not something that you can do given the current command line arguments.

Wednesday, April 15, 2015

Using Analytic and Debug Logs


It's common for IT administrators to use the native Windows logs to search for problems.  Two of the most commonly used logs are the "System" and the "Application" logs.  However, not everyone takes advantage of the the other built in operational logs.  When you go to event viewer, you can expand "Applications and Services Logs" to reveal a vast array of logs. Many of them are empty, but many of them are capturing useful data that can help you discover what is going on with your computer.

For more information on what each of these logs and log types are visit this link https://technet.microsoft.com/en-us/library/cc722404.aspx

In this post, I want to talk about the analytic and debug logs.  The Windows Logs give you information across your system.  It will show you hardware events, system events, security events, application events, etc.  It will do this for all sorts of components and application.  The Applications and Services Logs will drill into individual components and report only on those.

Friday, February 6, 2015

Using NetSh to Capture Network Traces



Scenario


You have a client / server application that appears is running slowly and you suspect the issue is network related.  You want to capture a network trace from the client and the server at the same time, but you don't want to install Wireshark or Network Monitor on either machine.

Netsh Trace


In the above scenario, it is important to get a simultaneous network trace from the client and the server while the problem is occurring. Open an administrative command prompt on both the client and on the server.  Enter the following command into both prompts:

netsh trace start capture=yes

Then launch the application to reproduce the slowness,  If it takes a long time for the application to launch, then continue to capture until the application is fully launched.  If some functionality within the application is slow, then be sure to capture the entire period of slowness in your trace.

Once you have gathered the data you need, use the following command to stop the trace:

netsh trace stop

Your command line should look like the above command line.  Notice that, by default, the max size of the trace file will be 250MB, that it is a circular (will overwrite the oldest data once the file size reaches 250MB), and you can see that it will show you the path were the .etl trace will be stored.

Sunday, September 7, 2014

How to Setup Performance Monitor Data Collector Sets to Monitor System Performance

Scenario

Are you having issues with the performance of your PC or server?  If so, you can use Microsoft's Performance Monitor to see performance trends over a period of time.  In this post, I will talk about how to collect the data you need in order to assess your issue. I will talk more about analysis of the data you collect in other posts.

Overall Steps for Data Collection


  1. Create two DCS.
  2. Start both DCS.
  3. Wait for the performance issue to occur.
  4. After you are sure that you captured data during the problem, stop the DCR.

We will be creating two separate data collector sets.  We will basically create two identical data collector sets.  The only difference between the two sets will be the polling interval.  Performance Monitor data collector sets poll data collectors providers at a whatever interval you specify.  We will set one of the intervals to 2 seconds and the other to 4 minutes.

Why would we do this?

In order to catch problems related to the CPU, we will need to poll at intervals no greater than 3 seconds.  For memory issues, we need the interval to be longer.  We will be creating circular logs which will overwrite the oldest data once they reach their size limit.  In the case of memory issues, we usually want to collect data over a period of days or even weeks.