IIS Trouble shooting Tools
1. LogParser
2.Debugdiag
3.Process Monitor
4.Resource Monitor
5.Fiddler
LogParser
Introduction:
Log Parser is a command line (yes, command line!) tool that uses a SQL dialect to extract information from data sources.
you should be familiar with the
following elements of a SELECT statement: TOP, FROM, INTO, WHERE,
ORDER BY, GROUP BY. That’s all you need to perform most Log
Parser operations.
Flavors:
Log Parser comes in two flavors, command-line & component-based (com object dll), for those who prefer direct interaction or automated. This allows users to use the tool in web-based applications or with ease via script such as vbscript or jscript.
Input Formats:
I couldn’t begin to list all the output formats that are supported by Log Parser. The list scrolls beyond the screen in the help file so I suggest you visit it when time permits. However, from a IIS-centric mindset let me tell you some of the things that I use it for:
Conversion: The ability to convert one log file format to another. This is useful if you are using say Centralized Binary Logging (2K3 only) and would like a readable format such as W3C. This can be done easily using Log Parser.
IIS Log Files: No matter the log file type, you can easily indicate using -i:<file format> the type of log file and Log Parser will pick that up and understand it (including built-in functions such as understanding <1> means the /w3svc/1 log file.
Event Viewer: This is very useful to locate error events thrown by the key IIS services such as w3wp, etc.
Network Monitor: You got it — it can parse those big ‘ole netmon traces to locate specific traffic you are interested in and only that traffic.
Output Formats:
NAT: This is the default, but not necessarily the best. This simply will return the results to the screen but this is not really useful sometimes as the data might be hard to read or more often TOO BIG.
Datagrid: This is nice for formatting data in a easy-to-read format though it is again still slightly limited. I use it often as I am not in the world of automation that many of you are so forgive my passion for it. However, if you do choose to use it then you should learn the -rtp switch that allows you to tell Log Parser exactly how many rows to print when extracting the data. This can be done using -rtp:-1 (all rows no matter how many) or using -rtp:10 to only print 10 rows.
SQL: Yep, you can easily take data from the log files and input into SQL server. This is very useful by allowing administrators the ability to hand-pick (via SQL commands) only the data they are interested in rather than the “entire” file.
For log parser commands please fallow the link
http://mlichtenberg.wordpress.com/2011/02/03/log-parser-rocks-more-than-50-examples/
____________________________________________________________________
Debug Diagnostic Tool:The Debug Diagnostic Tool is a tool designed to help troubleshoot performance issues with Internet Information Services (IIS). Even though the tool was designed with troubleshooting IIS in mind it can be used to identify performance issues for any process.The Debug Diagnostic Tool (DebugDiag) is designed to assist in troubleshooting issues such as hangs, slow performance, memory leaks or fragmentation, and crashes in any user-mode process. The tool includes built-in analysis rules focused on Internet Information Services (IIS) applications, web data access components, COM+, SharePoint and related Microsoft technologies.Microsoft Downloads - Debug Diagnostic Tool v2.0
Versions:
DebugDiag 1.0 released as part of the IIS Diagnostic Toolkit and as a standalone tool (x86 only).
- DebugDiag 1.1 released as a standalone tool only (x86 and limited x64 support).
- DebugDiag 1.2 released as a standalone tool only (x86 and
full x64 support).
- DebugDiag 2.0 released as a
new analysis engine host with built-in reporting framework that can
be accessed from .NET.
Collection Module:
============
The collection module is composed of three main components: The Debugging service, the debugger host and the user interface. It is the base install component of the tool.
- Debugging service: DbgSvc.exe. The Debugging Service performs the following tasks: ...
- Debugger Host : DbgHost.exe. The Debugger Host hosts the Windows Symbolic Debugger Engine (dbgeng.dll) to attach to processes and generate memory dumps. Dbghost.exe has no dependency on the service “DbgSvc.exe” and can be used separately.
- User Interface: DebugDiag.Collection.exe. The User Interface
allows generation of control scripts, manual dump generation,
displaying of rules status…etc. It is composed of two views: ...
============
The analysis module is selected by default in a typical install; however, you can deselect the feature if not needed. The analysis module requires .NET 4.0 installed on the system.
- Analysis Engine: dbglib.dll, DebugDiag.DotNet.dll The analysis engine loads in the Analysis UI. It uses the Windows Symbolic Debugger Engine (dbgeng.dll) to access userdump data. It exposes this data via a rich API set that you can call from .NET code.
- Analysis UI: DebugDiag.Analysis.exe The analysis UI is a .NET 4.0 executable that allows you to runs selected "Analysis Rules" against one or more memory dumps. ...
- Rule Builder: DebugDiag.RuleBuilder.exe The Rule builder UI
is a .net 4.0 Workflow application that allows you to create simple
workflow analysis rules...
Before you start Debug Diagnostics 1.1, you must identify the type of issue you are experiencing. For example, determine whether the application stops responding, crashes, performs slowly, or leaks memory. After you know the kind of issue, you can configure the Debug Diagnostics 1.1 tool to gather the correct data. Then, you can use the data to determine and resolve the cause of the problem."
The Debug Diagnostics 1.1 tool includes three views:
- Rules: Uses a wizard to create control scripts for the
debugger host.
- Advanced analysis: Runs the selected analysis script
on one or more memory dump files.
- Processes: Displays the status of running processes
and scripts.
- Go to Start -> Run, type the path of the Debug Diagnostics
1.0 tool, and then click OK. (By default, the Debug Diagnostics 1.0
tool is located inC:Program FilesIIS ResourcesDebugDiag.) If the
Select Rule Type dialog box appears, click Cancel.
Select the memory dump file that you want to analyze: Go to Start -> Run, type the path of the Debug Diagnostics 1.0 tool, and then click OK. Click the Advanced Analysis tab, and then click Add Data Files. Now select the memory dump file that you want to analyze and click Open.
- Configure the path for the symbol files: Navigate to
Start -> Run, type the path of the Debug Diagnostics 1.0 tool,
and then click OK. On the Tools menu, click Options and Settings. Go
to the Folders and Search Paths tab, type the following path in the
Symbol Search Path for Analysis box, and then click OK:
srv*filepath*http://msdl.microsoft.com/download/symbols
(Filepath is a placeholder for the folder or for the UNC share where
you want to store the downloaded symbol files. By default, the
symbol files are stored in the C:\ Symcache folder. Additionally,
you should know that you cannot browse the
http://msdl.microsoft.com/download/symbols Web site -- only
debugging tools can access this Web site.)
- Start the analysis: Go to Start -> Run, type the
path of the Debug Diagnostics 1.0 tool, and then click OK. Navigate
to the Advanced Analysis tab -> Available Analysis Scripts, and
select the type of analysis that you want. For example, if you
created the memory dump file because a process stopped responding,
click Crash/Hang Analyzers. If you created the memory dump file to
troubleshoot a memory leak issue, click Memory Pressure Analysis.
Now, under Data Files, click the memory dump file that you selected
in step 3. Click Start Analysis.
After completing the steps above, you can review the Debug Diagnostics report that is displayed in Microsoft Internet Explorer. A copy of the report is also stored in the following folder: C:\ Program Files \ IIS Resources\ DebugDiag\Reports. The report is broken down into the following sections:
- Analysis Summary: In this section, the detected issues
are classified as errors, warnings, or information.
Each error includes a description. Additionally, the Analysis
Summary contains recommendations for how to resolve the issues. The
recommendations may include reviewing a Microsoft Knowledge Base
article, contacting the application vendor, or contacting Microsoft
Product Support Services. Suggestions to the application developer
may also be provided.
- Analysis Details: This section provides a detailed
analysis of the information in the memory dump file.
- Script Summary: This section provides a report on the status of the script (Iisanalysis.asp) that is used to analyze the memory dump file. If an error occurs when the script is running, the Script Summary reports the error code, the source, the destination, and the lines of code that cause the error.
Fiddler:
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.
Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and thousands more. You can also debug traffic from popular devices like Windows Phone, iPod/iPad, and others.
http://fiddler2.com/
Getting Started with Fiddler
First, Install Fiddler.
Next, Configure the Fiddler Server.
The Fiddler Server is the machine on which Fiddler is installed. Some scenarios may require specific steps for Fiddler to receive and send web traffic. This includes:- Types of traffic, like decrypting HTTPS and authenticating with channel-binding tokens
- Network configurations, like monitoring
a remote machine, chaining
to an upstream proxy, using
Fiddler as a Reverse Proxy, monitoring
local traffic or monitoring
dial-up and VPN connections
Last, Configure the Client.
The client is the source of the web traffic that Fiddler monitors. Some client applications, operating systems, and devices may require specific steps to send and receive traffic to and from Fiddler. This includes:- Browsers, like Firefox, Opera, or IE (when sending traffic to localhost)
- Devices, like Android,
iOS,
Windows
Phone 7, and PocketPC
devices
Process Monitor:
Process Monitor combines the old Process Monitor tool with the File Monitor (FileMon) and Registry Monitor (RegMon) tools. Process Monitor is one of the most versatile tools to use in troubleshooting. Issues we use Process Monitor for include:
- Troubleshoot Application Failures (installs and uninstalls, launch failures etc)
- Troubleshoot File System issues (access, permissions, etc)
- Troubleshoot Registry issues (access, permissions, etc)
- Enable Boot logging to monitor the system from boot
- Examine the stack of an Application
- Troubleshoot misleading error messages
- Determine the registry settings for an application
- Extract the .zip file, and run Procmon.exe
- Click Agree to the EULA screen
- Process Monitor will start logging automatically
In
the main toolbar, you'll see this set of buttons. By toggling
these buttons on / off, you can choose whether or not to view
the Registry Activity, the File System Activity and the Process
/ Thread activity.If you double click on an event in the log you can bring up the property sheet for that event which includes basic information about the event on the first tab. The Process Tab includes information about the path, the Process ID, the Parent Process ID, the User and relevant DLL files. Finally, the Stack tab provides a very basic view of the stack for that event. The stack output indicates Kernel-mode calls with a "K" and User-mode calls with a "U". If Process Monitor is able to locate symbols for images referenced in the trace it will attempt to resolve addresses to the functions in which they reside
http://blogs.technet.com/b/askperf/archive/2007/06/01/troubleshooting-with-process-monitor.aspx
_____________________________________________________________________________
Resource Monitor:
Resource Monitor is a system application in Microsoft windows operating systems. It is used to view information about the use of hardware (CPU, memory, disk, and network) and software (file handles and modules) resources in real time. Resource Monitor is available in Windows vista and onwards only.
The Resource Monitor window includes five tabs:
- CPU
- displays column lists of Processes, Services, Associated Handles and Associated Modules; charts of CPU Usage (separate for every core)
-
Memory
- displays overall Physical Memory consumption and separate consumption of every Process; charts of Used Physical Memory, Commit Charge and Hard Faults/sec
-
Disk
- displays Processes with Disk Activity, Disk Activity and Storage; charts of Disk Usage (KB/sec) and Disk Queue Length
-
Network
- displays Processes with Network Activity, Network Activity, TCP Connections and Listening Ports; charts of Network Usage (separate for every adapter) and TCP Connections
-
1.Choose Start→All Programs→Accessories→System Tools→Resource
Monitor.
2.%windir%\system32\perfmon.exe /res
3.%windir%\system32\resmon.exe
If you’re having trouble with a
program taking over your computer, slowing things down, or even
locking things up, you
can use the Reliability Data available in the Windows 7 Resource
Monitor to see what’s happening inside the computer. The Resource
Monitor will provide all the information in graphs and statistics.
http://www.dummies.com/how-to/content/how-to-use-the-resource-monitor-in-windows-7.html
No comments:
Post a Comment