Using Trace Points in Visual Studio for Debugging

 

Trace points are the new debugging aid in Visual Studio. Break points are the general feature in almost all debuggers but not trace points. It’s much popular in GDB community even it’s a bit late, Microsoft introduced trace points with Visual Studio 2005

Why we would use Trace points?
Sometimes during debugging it’s not possible to interrupt the program execution. The correctness of the program may affected by the delay introduced by the debugger. In such cases we can use trace points. As the name resembles break points breaks the execution of the program while trace points doesn’t (or optional). Trace points provide additional options to know the debugging information on Trace point location.

Take the following example. The function Display is being called from two different threads. To know from where the call been made, you can get the help of trace points. This scenario is common in a multi thread program

[sourcecode language='cpp']
#include

void DisplayFxn( int i )
{
printf( “\n%d”,i);
}

void ProcessValue(int i, const int nThreadID )
{
DisplayFxn(i);
}

DWORD WINAPI Thread1(LPVOID)
{
for(int i = 0; i< 100; i++ )
{
ProcessValue( i,GetCurrentThreadId());
Sleep(600);
}
return 0;
}

DWORD WINAPI Thread2(LPVOID)
{
for(int i = 0; i< 100; i++ )
{
ProcessValue( i,GetCurrentThreadId() );
Sleep(300);
}
return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
HANDLE h[2];
h[0] = CreateThread( 0,0, Thread1,0,0,0);
h[1] = CreateThread( 0,0, Thread2,0,0,0);

WaitForMultipleObjects(2,h,TRUE,INFINITE);
return 0;
}
[/sourcecode]

First of all you’ve to create a trace point. You can create trace points from the scratch or convert an existing break point to trace point.

image

Now it’s time to specify the configuration of your trace point.

image

As you’re seeing in the configuration box, you can simply print the values of your variable by just giving the variable name inside curly braces.

You can also apply the appropriate predefined keywords to get enough information on the execution context. The basic list of the keywords are shown in the configuration box itself. Beside this, you can also use $TICK get current CPU tick and $FILEPOSE to insert the current file position. You can see a sample construct above. It may give following result where it contains all the specified data in output

[sourcecode language='cpp']
IN: 20Fxn: DisplayFxn(int),Thread: 0x140C Thread2 CPU Tick:0x4EC5FE Call Stack: TracePointSample.exe!DisplayFxn()
TracePointSample.exe!ProcessValue()
TracePointSample.exe!Thread2()
kernel32.dll!76ea36d6()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!77a5883c()
ntdll.dll!77a5880f()

IN: 11Fxn: DisplayFxn(int),Thread: 0xF74 Thread1 CPU Tick:0x4EC6C9 Call Stack: TracePointSample.exe!DisplayFxn()
TracePointSample.exe!ProcessValue()
TracePointSample.exe!Thread1()
kernel32.dll!76ea36d6()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!77a5883c()
ntdll.dll!77a5880f()
[/sourcecode]

Ok it’s time for your own try. Remember once more, this can be used effectively in time-out debugging situation(server client where server has a put some time out but delay from client because of debugging), debugging paint operations etc…. Check the documentation as well for more information

 

Cleaning up intermediate temporary files

 

Preparing the source and binaries for delivery is often tedious task especially if you’ve lot of components and source files to deliver. Removing it’s temporary files created by compiler and linker is even harder.

I’ve been using Michael Dunn’s cool cleanup utility for long time to smoothen my project deliveries, which is freely available through codeproject.

dirclean2

The utility contains most of the temporary file extensions and if you wish to some more, it’s possible through it’s configuration window. The coolest thing is that, it’s integrated with Shell. So you can just right click on the folder and opt for cleaning. Cool no?

I advice to read the entire article OK, just read the below quote () taken from his original article before downloading the tool.(That’s why given the links to download at the end)

Important note for VS.NET users

On the NT-based OSes, the way that the shell handles extensions of more than 3 characters will cause problems for C# projects. The default behavior of the shell makes the wildcard *.res match .RESX files (it only compares the first three characters), and deleting the .RESX files will delete some resource information.

So, to avoid deleting those files, you can either remove *.res from the list of files to delete, or go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ FileSystem, and set the DWORD value Win95TruncatedExtensions to 0, then restart your computer. See KB article Q164351 for more info on this feature.

See the original article: A Utility to Clean Up Compiler Temp Files

Download binary: Download DLL (register the DLL to use it) – 13K 

You can extract the DLL to a safe place, and register using regsvr32 dll_path

Uninstall using the same way by passing regsvr32 /u dll_path

 

The case of explorer crash on closing last remaining window

 

I’ve been bugging with an explorer crash which recently appears in my Windows XP machine.

Problem : Explorer crashes on closing last remaining explorer window)

I can’t totally figure out what’s really happening inside. My vial guess was towards some problematic explorer plug-in or perhaps my machine might be infect by some malware. The chance for the latter is rare as I believe I’m running with the very latest updates of Norton Antivirus (I’m not saying Norton is completely risk free).

Anyway I decided for a postmortem debugging and installed Dr.Watson as my default application debugger (Run-> drwtsn32 –I). But what really happened was, on crashing explorer window, Dr.Watson was getting hang and not dumping the explorer process. Again the default application debugger changed to WinDBG (Run->($Debugging-Tools-path)\WinDBG.exe –I ).

then I reproduced the problem again and WinDBG caught the exception. When I checked the problematic thread’s call stack, I could see that, the issues are happening with a thread which is trying to unload

[sourcecode language='cpp']
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
0436ffa8 001e02ba 000047c4 0436ffec 7c80b713 +0x16ce
0436ffb4 7c80b713 02c7ee5c 00000000 00000000 0x1e02ba
0436ffec 00000000 03151685 02c7ee5c 00000000 kernel32!BaseThreadStart+0×37
[/sourcecode]

Also, when I checked using “lm” command, it has given the loaded and unloaded modules’ list. In the unloaded modules list, iefdm2.dll was there. It was quite sure that the problematic DLL was a plug-in DLL named iefdm2.dll which solely belongs to “Free Download Manager”. FDM ver 2.5 was installed in my system. My Internet Explorer version was IE 8 – Beta and recently updated to RC1.

Solution: The latest version (ver 3.0) is working fine without any problems in my machine. If you’re not ready for an upgrade, the best thing can do is to disable particular add-on and sacrifice the FDM-IE integrated services. Disable add-on from Tools->Options->Programs(Tab)->Manage Addon, See the figure below.

Ad2

If you’re much interested in further debugging analysis, see the below output from “analyze –v” command
[sourcecode language='cpp']
FAULTING_IP:
iefdm2+16ce
02f516ce ?? ???

EXCEPTION_RECORD: ffffffff — (.exr 0xffffffffffffffff)
ExceptionAddress: 02f516ce (+0x000016ce)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 02f516ce
Attempt to read from address 02f516ce

FAULTING_THREAD: 00001f40
DEFAULT_BUCKET_ID: BAD_INSTRUCTION_PTR
PROCESS_NAME: explorer.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 – The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.
READ_ADDRESS: 02f516ce
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
IP_MODULE_UNLOADED:
iefdm2+16ce
02f516ce ?? ???

LAST_CONTROL_TRANSFER: from 000e0908 to 02f516ce
PRIMARY_PROBLEM_CLASS: BAD_INSTRUCTION_PTR
BUGCHECK_STR: APPLICATION_FAULT_BAD_INSTRUCTION_PTR
IP_ON_HEAP: 000e0908
FRAME_ONE_INVALID: 1
STACK_TEXT:
02f516ce iefdm2

FAILED_INSTRUCTION_ADDRESS:
iefdm2+16ce
02f516ce ?? ???

FOLLOWUP_IP:
iefdm2+16ce
02f516ce ?? ???

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: iefdm2+16ce

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: iefdm2

IMAGE_NAME: iefdm2.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 48588784
STACK_COMMAND: dds 2f516ce ; kb
FAILURE_BUCKET_ID: BAD_INSTRUCTION_PTR_c0000005_iefdm2.dll!Unloaded
BUCKET_ID: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_BAD_IP_iefdm2+16ce
Followup: MachineOwner
———
[/sourcecode]

 

Proudly powered by WordPress
Theme: Esquire by Matthew Buchanan.