Saturday, September 5, 2009

What is winDBG???

WinDbg is a multipurpose debugger for Microsoft Windows, distributed on the web by Microsoft. It can be used to debug user mode applications, drivers, and the operating system itself in kernel mode. It is a GUI application, but has little in common with the more well-known, but less powerful, Visual Studio Debugger.

WinDbg can be used for debugging kernel-mode memory dumps, created after what is commonly called the Blue Screen of Death which occurs when a bug check is issued. It can also be used to debug user-mode crash dumps. This is known as Post-mortem debugging.

WinDbg also has the ability to automatically load debugging symbol files (e.g., PDB files) from a server by matching various criteria (e.g., timestamp, CRC, single or multiprocessor version). This is a very helpful and time saving alternative to creating a symbol tree for a debugging target environment. If a private symbol server is configured, the symbols can be correlated with the source code for the binary. This eases the burden of debugging problems that have various versions of binaries installed on the debugging target by eliminating the need for finding and installing specific symbols version on the debug host. Microsoft has a public symbol server that has most of the public symbols for Windows 2000 and later versions of Windows (including service packs).

Recent versions of WinDbg have been distributed as part of the free Debugging Tools for Windows suite, which shares a common debugging engine between WinDbg. This means that most commands will work in all alternative versions without modification, allowing users to use the style of interface with which they are most comfortable.

Thursday, August 27, 2009

What is BoudsChecker : Memory Leak Testing Tool

BoundsChecker is a memory checking tool used for C++ software development with Microsoft Visual C++. It is part of the DevPartner for Visual C++ BoundsChecker Suite. Comparable tools are Purify, Insure++ and Valgrind.

BoundsChecker can be run in two modes: ActiveCheck, which does not instrument the application, and FinalCheck, which does.

ActiveCheck performs a less intrusive analysis and monitors all calls by the application to the C Runtime Library, Windows API and calls to COM objects. By monitoring memory allocations and releases, it can detect memory leaks and overruns. Monitoring API and COM calls enables ActiveCheck to check parameters, returns and exceptions and report exceptions when they occur. Thread deadlocks can also be detected by monitoring of the synchronization objects and calls giving actual and potential deadlock detection.

FinalCheck requires an instrumented build and gives a much deeper but more intrusive analysis. It provides all of the detection features of ActiveCheck plus the ability to detect buffer overflows (read and write) and uninitialized memory accesses. It monitors every scope change, pointer and memory usage.

Filtering Mechanisms in Fiddler: Can we see filtered http calls made through a particular Application?

Yes, Fiddler provide very efficient ways to filter http requests generated through particular application. Here are the steps to achieve this:

- Launch fiddler
- Start your Application
- Launch Fiddler
- Go to Filter tab on right hand side
- Check "Use Filters" option
- Now all filter parameters will be enabled.
- Go to "Client process" section
- Check option : "Show traffic only from"
- Now a dropdown will be enabled >> Select the exe you want to monitor
- This dropdown shows all the processes running on your machine

Apart from this, there are different type of Filters.

1. Filtering on the basis of Hosts. E.g.- you can opt to see only those calls which are made on www.google.com
2. You can also opt for seeing calls which are failing by selecting option for hiding success calls :)
3. We can filter on the basis on content : Images, Text, HTTP, Scripts...

Explore Filter Menu in details....

Tuesday, August 25, 2009

What is Filemon?

FileMon monitors and displays file system activity on a system in real-time. Its advanced capabilities make it a powerful tool for exploring the way Windows works, seeing how applications use the files and DLLs, or tracking down problems in system or application file configurations. Filemon's timestamping feature will show you precisely when every open, read, write or delete, happens, and its status column tells you the outcome. FileMon is so easy to use that you'll be an expert within minutes. It begins monitoring when you start it, and its output window can be saved to a file for off-line viewing. It has full search capability, and if you find that you're getting information overload, simply set up one or more filters.

Filtering

Use the Filter dialog, which is accessed with a toolbar button or the Edit|Filter/Highlight menu selection, to select what data will be shown in the list view. The '*' wildcard matches arbitrary strings, and the filters are case-insensitive. Only matches shown in the include filter, but that are not excluded with the exclude filter, are displayed. Use ';' to separate multiple strings in a filter (e.g. "filemon;temp"). Windows NT/2000 note: because of the asynchronous nature of file I/O, its not possible to filter on the result field.

For example, if the include filter is "c:\temp", and the exclude filter is "c:\temp\subdir", all references to files and directories under c:\temp, except to those under c:\temp\subdir will be monitored.

Wildcards allow for complex pattern matching, making it possible to match specific file accesses by specific applications, for example. The include filter "Winword*Windows" would have FileMon only show accesses by Microsoft Word to files and directories that include the word "Windows".

Use the highlight filter specify output that you want to have highlighted in the listview output. Select highlighting colors with Edit|Highlight Colors.

Additional filter options select or deselect read, write or open operations. In many troubleshooting scenarios only open operations are of interest, for example.

Selecting Volumes (Windows NT/2K/XP/2K3)

The Volumes menu can be used to select and deselect monitored volumes. Select the Network menu item to monitor accesses to any network resources, including remote shares and UNC path name accesses to remote volumes.

Limiting Output


The History Depth dialog, accessed via toolbar button or the Edit|History menu item, allows you to specify the maximum number of lines that will be remembered in the output window. A depth of 0 is used to signify no limit.

Searching the Output


You can search the output window for strings using the Find menu item (or the find toolbar button). You can repeat the search in the forward direction with the F3 key and in reverse with Shift+F3. To start a search at a particular line in the output, select the desired line by clicking on the far left column (the index number). If no line is selected a new search starts at the first entry in searching down, and at the last entry for searching up.

Options


FileMon can either timestamp events or show their duration. The Options menu and the clock toolbar button let you toggle between the two modes. The button on the toolbar shows the current mode with a clock or a stopwatch. When showing duration the Time field in the output shows the number of seconds it took for the underlying file system to service particular requests. The Options|Show Milliseconds menu entry lets you add millisecond resolution to times presented when FileMon shows clock times.

You can toggle FileMon to always remain a top window with the Options|Always On Top menu item. In addition, you can toggle FileMon not to scroll the listview via the Options|Auto Scroll menu item or corresponding toolbar button.

Named Pipes and Mail Slots

Starting in version 4.1 FileMon is able to monitor named pipe and mail slot file system activity on Windows NT/2K. Named pipes are commonly used as a communications mechanism in NT/Win2K by core subsystems like the Local Security Authority Subsystem (LSASS), and are used by DCOM. They are also used by network components such as the Browser service. To see named pipe activity with FileMon select Named Pipes in the Drives menu and perform an operation on a shared network resource, or open an application such as Regedt32 that interacts with the security subsystem.

How FileMon Works


For the Windows 9x driver, the heart of FileMon is in the virtual device driver, Filevxd.vxd. It is dynamically loaded, and in its initialization it installs a file system filter via the VxD service, IFSMGR_InstallFileSystemApiHook, to insert itself onto the call chain of all file system requests. On Windows NT the heart of FileMon is a file system driver that creates and attaches filter device objects to target file system device objects so that FileMon will see all IRPs and FastIO requests directed at drives. When FileMon sees an open, create or close call, it updates an internal hash table that serves as the mapping between internal file handles and file path names. Whenever it sees calls that are handle based, it looks up the handle in the hash table to obtain the full name for display. If a handle-based access references a file opened before FileMon started, FileMon will fail to find the mapping in its hash table and will simply present the handle's value instead.

What is DBGView?

Its a very useful application developed by SysInternals which is acquired by Microsoft now.

DebugView
is an application that lets you monitor debug output on your local system, or any computer on the network that you can reach via TCP/IP. It is capable of displaying both kernel-mode and Win32 debug output, so you don't need a debugger to catch the debug output your applications or device drivers generate, nor do you need to modify your applications or drivers to use non-standard debug output APIs.


DebugView Captures:


Under Windows 2000, XP, Server 2003 and Vista DebugView will capture:

* Win32 OutputDebugString
* Kernel-mode DbgPrint
* All kernel-mode variants of DbgPrint implemented in Windows XP and Server 2003

DebugView also extracts kernel-mode debug output generated before a crash from Window's 2000/XP crash dump files if DebugView was capturing at the time of the crash.


Simply execute the DebugView program file (dbgview.exe) and DebugView will immediately start capturing debug output. Note that if you run DebugView on Windows 2000/XP you must have administrative privilege to view kernel-mode debug output. Menus, hot-keys, or toolbar buttons can be used to clear the window, save the monitored data to a file, search output, change the window font, and more. The on-line help describes all of DebugView's features.