Thread Information Block (TIB) and FS Register

Tip - TIB is a structure that stores the information about currently running thread. The ‘winnt.h’ contains a structure called NT_TIB which defines the TIB.

Details - The structure is:

typedef struct _NT_TIB

{

    struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList;

    PVOID StackBase;

    PVOID StackLimit;

    PVOID SubSystemTib;

    union

   {

        PVOID FiberData;

        DWORD Version;

   };

    PVOID ArbitraryUserPointer;

    struct _NT_TIB *Self;

} NT_TIB;

The TIB can be accessed as an offset of segment register FS. FS is the data selector to TIB for the first thread. FS maps to a TIB which is embedded in a data block known as the TDB (thread data base). The TIB contains the thread-specific exception handling chain and pointer to the TLS (thread local storage.)

The functions such as GetCurrentProcessId(), GetCurrentThreadId(), GetLastError() etc fetches the values from TIB. For example, the code inside the function GetCurrentProcessId() may look like…

DWORD GetCurrentProcessId()

{

    DWORD dwProcessID = 0;

    __asm

    {

        mov eax, fs:[0x20]

        mov dwProcessID, eax

    }   

    return dwProcessID;

}

Contents of TIB (Please check the reference link for the complete details):

Position	Length	Windows Versions	Description
FS:[0x00]	4	Win9x and NT	Current Structured Exception Handling (SEH) frame
FS:[0x04]	4	Win9x and NT	Top of stack
FS:[0x08]	4	Win9x and NT	Current bottom of stack
FS:[0x10]	4	NT	Fiber data
FS:[0x14]	4	Win9x and NT	Arbitrary data slot
FS:[0x18]	4	Win9x and NT	Linear address of TIB
-	-	NT	End of NT subsystem independent part
FS:[0x20]	4	NT	Process ID
FS:[0x24]	4	NT	Current thread ID
FS:[0x2C]	4	Win9x and NT	Linear address of the thread-local storage array
FS:[0x30]	4	NT	Linear address of Process Environment Block (PEB)
FS:[0x34]	4	NT	Last error number
FS:[0x38]	4	NT	Last status number
FS:[0x3C]	4	NT	Count owned locks
FS:[0x40]	4	NT	Hard errors mode
FS:[0x60]	4	Win95/Win98	Last error number
FS:[0x74]	4	WinME	Last error number

Reference   -

http://en.wikipedia.org/wiki/Win32_Thread_Information_Block

http://www.nirsoft.net/kernel_struct/vista/NT_TIB.html

Posted By :Jijo Krishnan

Adding Console into GUI applications

Tip - To add Console into a GUI application (Dialog based, SDI or MDI), use AllocConsole() and freopen(). AllocConsole() allocates a new console for the calling process.

Details - While debugging an application it is often useful to have trace output window for data logging rather than using MessageBox or OutputDebugString. An easiest method is to create a console window and redirect standard I/O to it like the following:

AllocConsole();

freopen("conin$", "r", stdin);

freopen("conout$", "w", stdout);

freopen("conout$", "w", stderr);

After this, all printf and cout calls will output to the console window.

Even input will work for it. We can use getch() from conio.h to pause a thread. A process can be associated with only one console, so the AllocConsole() function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console. This function is primarily used by graphical user interface (GUI) application to create a console window. The standard input handle is a handle to the console's input buffer and the standard output and standard error handles are handles to the console's screen buffer.

Reference   -

http://msdn.microsoft.com/en-us/library/ms681944.aspx

Posted By :Jijo Krishnan

Using StackWalk, MiniDumpWriteDump APIs for getting CallStack info

Tip -

StackWalk - Obtains a stack trace.

MiniDumpWriteDump - Writes minidump information to the specified file.

Details - 

StackWalk

In some cases we need to display the callstack of the current thread or the callstack of other threads/processes. This will be helpful for the application crash analysis etc.

Syntax:

                    StackWalk(

                 DWORD MachineType,

                 __in HANDLE hProcess,

                 __in HANDLE hThread,

                 __inout LPSTACKFRAME StackFrame,                      

                 __inout PVOID ContextRecord,

                 __in_opt PREAD_PROCESS_MEMORY_ROUTINE ReadMemoryRoutine,

                 __in_opt PFUNCTION_TABLE_ACCESS_ROUTINE FunctionTableAccessRoutine,

                 __in_opt PGET_MODULE_BASE_ROUTINE GetModuleBaseRoutine,

                 __in_opt PTRANSLATE_ADDRESS_ROUTINE TranslateAddress

                 );

This interface is in the dbghelp.dll library. The latest dbghelp.dll can be downloaded with the “Debugging Tools for Windows” available in http://www.microsoft.com/whdc/devtools/debugging/default.mspx.

 

MiniDumpWriteDump

Writes user-mode minidump information to the specified file. This helps to dump the call stack information to the specified file. The dump data can be analyzed using WinDbg. This interface is also in the dbghelp.dll library.

Syntax:

BOOL WINAPI MiniDumpWriteDump(

  __in  HANDLE hProcess,

  __in  DWORD ProcessId,

  __in  HANDLE hFile,

  __in  MINIDUMP_TYPE DumpType,

  __in  PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,

  __in  PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,

  __in  PMINIDUMP_CALLBACK_INFORMATION CallbackParam

);

Reference   -

1. http://msdn.microsoft.com/en-us/library/ms680650(v=vs.85).aspx

    http://www.codeproject.com/KB/threads/StackWalker.aspx

2. http://msdn.microsoft.com/en-us/library/ms680360(v=vs.85).aspx

    http://msdn.microsoft.com/en-us/library/ee416349(v=vs.85).aspx

Posted By :Jijo Krishnan

ProcDump

Tip - A general process dump utility.

Details - ProcDump is a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike that an administrator or developer can use to determine the cause of the spike. ProcDump also includes hung window monitoring (using the same definition of a window hang that Windows and Task Manager use), unhandled exception monitoring and can generate dumps based on the values of system performance counters. It also can serve as a general process dump utility that you can embed in other scripts.

 

Reference -

http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

Posted By :Sumesh V V

Virtual functions & Inline constructors

Tip -Virtual functions & Inline constructors

Details - When an object containing virtual functions is created, its VPTR must be initialized to point to the proper VTABLE. This must be done before there’s any possibility of calling a virtual function. A constructor cannot be virtual because at the time when the constructor is invoked the virtual table would not be available in the memory. Hence we cannot have a virtual constructor. As you might guess, because the constructor has the job of bringing an object into existence, it is also the constructor’s job to set up the VPTR. The compiler secretly inserts code into the beginning of the constructor that initializes the VPTR. In fact, even if you don’t explicitly create a constructor for a class, the compiler will create one for you with the proper VPTR initialization code (if you have virtual functions). This has several implications.

 

The first concerns efficiency. The reason for inline functions is to reduce the calling overhead for small functions. If C++ didn’t provide inline functions, the preprocessor might be used to create these “macros.” However, the preprocessor has no concept of access or classes, and therefore couldn’t be used to create member function macros. In addition, with constructors that must have hidden code inserted by the compiler, a preprocessor macro wouldn’t work at all.

 

You must be aware when hunting for efficiency holes that the compiler is inserting hidden code into your constructor function. Not only must it initialize the VPTR, it must also check the value of this (in case the operator new returns zero) and call base-class constructors. Taken together, this code can impact what you thought was a tiny inline function call. In particular, the size of the constructor can overwhelm the savings you get from reduced function-call overhead. If you make a lot of inline constructor calls, your code size can grow without any benefits in speed.

 

Of course, you probably won’t make all tiny constructors non-inline right away, because they’re much easier to write as inline. But when you’re tuning your code, remember to remove inline constructors.

 

Reference -

 http://sumeshvv.wordpress.com/2010/12/02/virtual-functions-inline-constructors/

Posted By :Sumesh V V

Behavior of virtual functions in constructors – C++

Tip-Behavior of virtual functions in constructors – C++

Details - The hierarchy of constructor calls brings up an interesting dilemma. What happens if you’re inside the constructor of a base class and you call a virtual function? Inside an ordinary member function you can imagine what will happen – the virtual call is resolved at runtime because the object cannot know whether it belongs to the class the member function is in, or some class derived from it. For consistency, you might think this is what should happen inside constructors. This is not the case. If you call a virtual function from the constructor of a base class, only the local version of the function is used. That is, the virtual mechanism doesn’t work within the constructor of base class.

This behavior makes sense for two reasons. Conceptually, the constructor’s job is to bring the object into existence. Inside any constructor, the object may only be partially formed – you can only know that the base-class objects have been initialized, but you cannot know which classes are inherited from you. A virtual function call, however, reaches “forward” or “outward” into the inheritance hierarchy. It calls a function in a derived class. If you could do this inside a constructor, you’d be calling a function that might manipulate members that hadn’t been initialized yet, a sure recipe for disaster.

The second reason is a mechanical one. When a constructor is called, one of the first things it does is initialize its VPTR. However, it can only know that it is of the “current” type. The constructor code is completely ignorant of whether or not the object is in the base of another class. When the compiler generates code for that constructor, it generates code for a constructor of that class, not a base class and not a class derived from it (because a class can’t know who inherits it). So the VPTR it uses must be for the VTABLE of that class. The VPTR remains initialized to that VTABLE for the rest of the object’s lifetime this isn’t the last constructor call. If a more-derived constructor is called afterwards, that constructor sets the VPTR to VTABLE, and so on, until the last constructor finishes. The state of the VPTR is determined by the constructor that is called last. This is another reason why the constructors are called in order from base to most-derived.

But while all this series of constructor calls is taking place, each constructor has set the VPTR to its own VTABLE. If it uses the virtual mechanism for function calls, it will produce only a call through its own VTABLE, not the most-derived VTABLE (as would be the case after the constructors were called). In addition, many compilers recognize that a virtual function call is being made inside a constructor, and perform early binding because they know that late-binding will produce a call only to the local function. In either event, you won’t get the results you might expect from a virtual function call inside a constructor.

[Code] 

class Base

{

public:

    Base()

    {

        DoSomething();

    }

    virtual ~Base()

    {

    }

    // This will be overridden in the derived type.

    virtual void DoSomething()

    {

        printf( "Base::DoSomething\r\n" );

    }

};

class DerivedType : public Base

{

public:

    DerivedType ()

    {

    }

    ~DerivedType ()

    {

    }

    void DoSomething()

    {

        printf( "DerivedType::DoSomething\r\n" );

    }

};

int _tmain(int argc, _TCHAR* argv[])

{

    Base *pDerivedType = new DerivedType();

    // Code here

    if( NULL != pDerivedType )

    {

        delete pDerivedType;

        pDerivedType = 0;

    }

    return 0;

}

Output:

Base::DoSomething

Reference   -

http://sumeshvv.wordpress.com/2010/12/02/virtual-functions-in-constructors-cplusplus/

http://sumeshvv.wordpress.com/2010/12/06/do-not-call-overridable-methods-in-constructors-csharp/

Posted By :Sumesh V V

How the OutputDebugString() API works

Tip - How the OutputDebugString() API works

Details - Hardcore Win32 developers are probably familiar with the OutputDebugString() API function that lets your program talk with a debugger.

When OutputDebugString() is called by an application, it takes the following steps.

1. Open DBWinMutex and wait until we have exclusive access to it.
2. Map the DBWIN_BUFFER segment into memory. If it’s not found, there is no debugger running so the entire request is ignored.The DBWIN_BUFFER when present, is organized like this structure. The process ID shows where the message came from, and string data fills out the remainder of the 4KB. By convention, a NULL byte is always included at the end of the message.

struct dbwin_buffer
{
  DWORD dwProcessId;
  // Total size must be 4KB ( dwProcessID + data )
  char data[4096-sizeof( DWORD )];
};

3. Open the DBWIN_BUFFER_READY and DBWIN_DATA_READY events. As with the shared memory segment, missing objects mean that no debugger is available.
4. Wait for the DBWIN_BUFFER_READY event to be signaled, this says that the memory buffer is no longer in use. Most of the time, this event will be signaled immediately when it’s examined, but it won’t wait longer than 10 seconds for the buffer to become ready (a timeout abandons the request).
5. Copy up to about 4KB of data to the memory buffer, and store the current process ID there as well. Always put a NULL byte at the end of the string.
6.Tell the debugger that the buffer is ready by setting the DBWIN_DATA_READY event. The debugger takes it from there.
7. Release the mutex
8. Close the Event and Section objects, though we keep the handle to the mutex around for later.

If we want to watch the strings outputted using OutputDebugString(), from the viewer application side it’s a bit simpler. The mutex is not used at all, and if the events or shared memory objects already exist, we presume that some other debugger is already running. Only one debugger can be in the system at a time.

1. Create the shared memory segment and the two events. If we can’t, exit.
2. Set the DBWIN_BUFFER_READY event so the applications know that the buffer is available.
3. Wait for the DBWIN_DATA_READY event to be signaled.
4. Extract the process ID and NULL-terminated string from the memory buffer.
5. Go to step #2

Unlike most of the Win32 API, the native version of OutputDebugString() is ASCII. So OutputDebugString() ultimately passes data to the debugger in the memory buffer strictly as ASCII. This suggests that for sending a quick message even in a Unicode program, it can be done by calling the OutputDebugStringA() version directly.

Reference - http://sumeshvv.wordpress.com/2010/12/02/how-the-outputdebugstring-api-works/

Posted By :Sumesh V V