32bit

[Article] Authoring a Stack Walker for X86

Gaurav Khanna — Mon, 07 Jan 2008 12:48:58 GMT

Stack walking is second nature to debuggers. But if you had more interest in it than just debugging and either:

wanted to know what stack walking is about, or
wanted to know how stack walking is implemented, or
wanted to know how a custom stack walker can be authored for your application

then you might find the article, Authoring a Stack Walker for X86, useful. Its my attempt to help clarify the basics of stack walking and explain key concepts and show how it can be implemented on x86 platform. The article can be read here and its accompanying stack walker implementation source code can be downloaded from here.

Below is an output from the stack walker implementation discussed in the article:

Advanced Windows Debugging

Gaurav Khanna — Sun, 23 Dec 2007 05:00:21 GMT

The book is a must have for every serious Windows developer!

Lessons in Exception Handling

Gaurav Khanna — Sun, 13 May 2007 23:50:29 GMT

Working on the CLR's exception handling subsystem is not just challenging but also gives unique opportunities to understand how the various exception handling subsystems (e.g. SEH, C++ EH, etc) work, and in particular, how they interoperate with one another. It was such case that had me discuss one such issue with Kevin, development lead of the JIT, that he mentions here.

That discussion got me exploring the interoperability aspects of EH further and resulted in the bullets listed below. Incase you are interested, download the PDF version of this article from here and the accompanying source code from here. For those uninitiated to exception handling, Matt Pietrek's must read article is here.

Now, onto the interoperability aspects of EH.

Note: the following discussion is in context of the x86 platform

Catching an exception using __try/__except SEH handler will result in RtlUnwind being called without exception record

Structured Exception Handling (SEH) is built into the Windows OS and it is how the OS processes the exceptions. Compilers offer their own specific ways of setting up a SEH handler. To setup one using Microsoft Visual C++, we use __try/__except keywords. For example:

__try
{
printf("Calling the /EHSc function\n");
InvokeCPPFunction();
}
__except (IsForUs(GetExceptionInformation()))
{
printf("In __except\n");
}

If the InvokeCPPFunction throws an exception, the OS will invoke the filter function (the IsForUs function referenced in the braces of __except) and check its return value. The filter function can be passed exception details that can be retrieved using the GetExceptionInformation function and using that information, it can decide whether it wants to process the exception or not.

If the filter function returns EXCEPTION_CONTINUE_EXECUTION, the OS retries the instruction that created the exception. However, if the return value is EXCEPTION_CONTINUE_SEARCH, it tells the OS that the filter function has declined to process the exception and the OS continues its search for the handler in the SEH handler chain (that is available from FS:0 on x86 machines for each OS thread).

The filter function can also return EXCEPTION_EXECUTE_HANDLER to tell the OS that it wants to handle the exception and the OS proceeds to invoke the funclet within the __except block. But before invoking the funclet, the OS has to unwind the call stack. On x86, the code generated by VC++ compiler does this by invoking RtlUnwind API, with NULL for the third argument - this argument is a pointer to the exception record for the exception being processed. This is done by the compiler by invoking GlobalUnwind (an internal function) after doing some processing. GlobalUnwind makes the call to RtlUnwind as shown below:
@_EH4_GlobalUnwind@4:
70508FB2 push ebp
70508FB3 mov ebp,esp
70508FB5 push ebx
70508FB6 push esi
70508FB7 push edi
70508FB8 push 0
70508FBA push 0
70508FBC push offset ReturnPoint (70508FC7h)
70508FC1 push ecx
70508FC2 call RtlUnwind (70526620h)
The highlighted red line is the one where NULL is pushed for exception record.
What this implies that all SEH handlers that are in the x86 FS:0 chain, prior to the one that agreed to process the exception, will be called by the OS once again to give them a chance to do some cleanup (e.g. release resources) – this is typically known as unwinding of the stack. And since the unwind was initiated with a NULL for the exception record, if your SEH handler relies on checking the exception record for details before deciding to do the cleanup, it can potentially fail (e.g. not end up doing the cleanup)!

Corollary Lesson: Don’t throw (and expect to catch correctly) exception across environment boundaries. E.g. throwing a C++ exception and trying to catch it using a SEH handler

Since a C++ application can have a mix of both C++ exception handling constructs and SEH exception handing constructs, it is easy to commit the mistake of writing code that throws an exception from C++ EH and excepts that to be correctly caught and processed in SEH EH constructs – the focus is on correct processing.

Let’s extend the previous example. Assume that InvokeCPPFunction is a function in a DLL that was compiled to use C++ EH (using the /EHSc switch) and implemented as shown below:

class CPPClass2
{
public:
CPPClass2()
{
printf("CPPClass2 constructor\n");
}
~CPPClass2()
{
printf("CPPClass2 destructor\n");
}
};

class CPPClass
{
public:
CPPClass()
{
printf("CPPClass constructor\n");
}
void ThrowException()
{
CPPClass2 cpp2;
throw 1;
}
~CPPClass()
{
printf("CPPClass destructor\n");
}
};

__declspec (dllexport) void InvokeCPPFunction()
{
CPPClass cpp;
cpp.ThrowException();
}

We have two classes, CPPClass & CPPClass2 that have destructors each. InvokeCPPFunction instantiates CPPClass object, cpp, and invokes the ThrowException method, which in turn, instantiates CPPClass2 object, cpp2, and throws an exception.
As per the C++ semantics, when this exception is caught, the destructors should be invoked as they are expected to do the cleanup for the respective class instance. However, this depends upon who catches the exception.
In our previous example, InvokeCPPFunction was invoked from within __try/__except SEH mechanism. Hence, when ThrowException throws an exception, the OS walks the FS:0 chain to look for a handler that will handle the exception. When the OS comes to our __except block, if the filter funclet returns EXECEPTION_EXECUTE_HANDLER, as per our last discussion, RtlUnwind is invoked with a NULL for the exception record pointer.
When this happens and the unwind call comes to C++ exception handler, the C++ EH does not process the unwind since the exception record is NULL. This is because C++ EH only processes the unwind when the exception code in the exception record has the C++ exception code (0Xe06d7363). Thus, no destructors are invoked and that is not something you want. Below is the output this example:

Hence, it’s important to catch the exception in the environment/EH-context it was thrown in, since that EH-context will know how to process it correctly.

Technorati tags: Exception Handling, RtlUnwind, RtlUnwindEx, Structured Exception Handling, SEH, C++ Exception Handling, FS:[0]

Adding process enumeration support in Rotor v1.0

Gaurav Khanna — Thu, 05 Jan 2006 17:44:00 GMT

[Original Post Date: 5th September 2005]

Share Source CLI, better known as Rotor, is one of the best ways to understand how .NET Framework works. And with the source code availability as part of Rotor distribution, its an excellent academic/hobby interest - you can extend it by adding more functionality, or modify the existing one and see how it behaves.

Yesterday, I went about doing the same. One of the functionality which I found missing in Rotor is that of enumerating system process list. .NET Framework's System.Diagnostics.Process class has methods, like GetProcesses, that allow you to do the same.

So, I went about implementing GetProcesses method overloadsin System.Diagnostics.Process class that allow me to enumerate process list on the local machine only. This required modification in the Platform Adaptation Layer (PAL) of Rotor. Since, I just have it running on Win32 for the moment, I modified the Win32 PAL to implement the support via ToolHelp API. Now, on a Windows system, its possible to enumerate the system process list using Rotor, as exemplified by the snippet below:

using System;

using System.Diagnostics;

publicclass EnumProcess

{

publicstaticvoid Main()

{

Process[] arrProcess = Process.GetProcesses();

if (arrProcess == null)

{

Console.WriteLine("Unable to get process list!");

return;

}
Console.WriteLine("{0} processes enumerated.",arrProcess.Length);

foreach (Process proc in arrProcess)

Console.WriteLine("Process ID {0}, Handle: {1}", proc.Id, proc.Handle);

}

You can download the updated source files for Rotor v1.0 from http://www.wintoolzone.com/showpage.aspx?url=rotor.aspx. The zipped archive contains Changes for Process Enumeration.txt that indicates where the updated files need to be copied. Once done, rebuild Rotor to get the changes into effect.

Shared Source Bluetooth Library

Gaurav Khanna — Fri, 27 May 2005 02:47:00 GMT

Check out the shared source Bluetooth class library - Windows Embedded Source Tools for Bluetooth

Win32 API -> .NET Framework Mapping

Gaurav Khanna — Wed, 02 Mar 2005 00:25:00 GMT

Do you want to know which Win32 API maps to what part of the .NET Framework? If yes, visit http://msdn.microsoft.com/netframework/programming/interop/default.aspx?pull=/library/en-us/dndotnet/html/win32map.asp

Managed code impersonation: CLR ThreadPool and more...

Gaurav Khanna — Wed, 09 Feb 2005 19:43:00 GMT

Under managed code, once you impersonate your application's thread using LogonUser and WindowsIdentity class's Impersonate method, you can go ahead and perform tasks using the impersonated thread as you require. However, there are couple of catches to this:

1) If you launch a process using Process.Start method, the launched process will not execute under the impersonation context of your application. If you want to make that happen, you will have to launch the process using CreateProcessWithLogonW as I have discussed at http://geekswithblogs.net/khanna/archive/2005/02/09/22430.aspx.

2) If, from the impersonated thread, you schedule some task to execute using QueueUserWorkItem of ThreadPool class, even the ThreadPool threads do not get the impersonated context, as shown below:

However, once the ThreadPool thread is impersonated, results are as expected:

Below is the snippet to accomplish this:

private static IntPtr LogUser(string strUsername, string strDomain, string strPassword)
		{
			IntPtr tokenHandle = new IntPtr(0);
			IntPtr dupeTokenHandle = new IntPtr(0);

			string UserName, MachineName,passWord;
			const int LOGON32_PROVIDER_DEFAULT = 0;
			//This parameter causes LogonUser to create a primary token.
			const int LOGON32_LOGON_INTERACTIVE = 2;
			const int SecurityImpersonation = 2;

			tokenHandle = IntPtr.Zero;
			dupeTokenHandle = IntPtr.Zero;

			// Call LogonUser to obtain a handle to an access token.
			bool returnValue = LogonUser(strUsername, strDomain, strPassword, 
				LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,
				ref tokenHandle);

				
			if (false == returnValue)
			{
				int ret = Marshal.GetLastWin32Error();
				return IntPtr.Zero;
			}

			WindowsIdentity mWI1 = WindowsIdentity.GetCurrent();
			IntPtr token2 = new IntPtr(tokenHandle.ToInt32());

			return token2;
		}

		/// 
		/// The main entry point for the application.
		/// 
		[STAThread]
		static void Main(string[] args)
		{
			// show current principal..
			IIdentity curI = null;
			curI = WindowsIdentity.GetCurrent();
			Console.WriteLine("Your current identity is {0}",curI.Name);
			
			// Impersonate
			IntPtr token = LogUser("username","domain","password!");
			WindowsIdentity mWI2 = new WindowsIdentity(token);
			WindowsPrincipal winPrin = new WindowsPrincipal(mWI2);
			System.Threading.Thread.CurrentPrincipal = winPrin;
			WindowsImpersonationContext impersonatedUser = mWI2.Impersonate();

			curI = WindowsIdentity.GetCurrent();
			Console.WriteLine("After impersonation in the main thread, you are {0}",curI.Name);

			ThreadPool.QueueUserWorkItem(new WaitCallback(callback));
			Console.ReadLine();
		}

		static void callback(Object stateInfo) 
		{
			// No state object was passed to QueueUserWorkItem, so 
			// stateInfo is null.
			Console.WriteLine("Hello from the thread pool.");

			IIdentity curI = null;
			curI = WindowsIdentity.GetCurrent();
			Console.WriteLine("In ThreadPool Thread, you are {0}",curI.Name);

			IntPtr token = LogUser("username","domain","password!");
			WindowsIdentity mWI2 = new WindowsIdentity(token);
			
			WindowsPrincipal winPrin = new WindowsPrincipal(mWI2);
			System.Threading.Thread.CurrentPrincipal = winPrin;
			WindowsImpersonationContext impersonatedUser = mWI2.Impersonate();

			curI = WindowsIdentity.GetCurrent();
			Console.WriteLine("After impersonation, in ThreadPool Thread, you are {0}",curI.Name);
		}

Managed CreateProcessWithLogonW

Gaurav Khanna — Wed, 09 Feb 2005 17:38:00 GMT

I returned this past weekend after a family function. It had me very busy and thus, no blogging for sometime for me :)

That said, today I was working with one of my friends over email - she was stuck about getting to launch a process in a specific user context, using managed code. Since the .NET Framework doesn't support such functionality out of the box, we tried different ways to do this:

1) LogonUser followed by WindowsIdentity impersonation using the obtained token - the token wasn't getting down to the spawned process even after we attempted Impersonate method of WindowsIdentity.
2) WMI also tried - it works but needs to be slightly modified when running on a local machine compared to a remote machine (we cannot specify credentials for local machine in the options).

Finally, we thought about working on CreateProcessWithLogonW. It turned out to be rather simple and clean way of achieving our goal. For those who are interested, the following snippet uses CreateProcessWithLogonW via PInvoke and launches a process under the specified user context:

The following are the PInvoke declarations and data types required:


        [Flags]
		enum LogonFlags 
	{
		LOGON_WITH_PROFILE         = 0x00000001,
		LOGON_NETCREDENTIALS_ONLY  = 0x00000002        
	}

	[Flags]
		enum CreationFlags 
	{
		CREATE_SUSPENDED           = 0x00000004,
		CREATE_NEW_CONSOLE         = 0x00000010,
		CREATE_NEW_PROCESS_GROUP   = 0x00000200,
		CREATE_UNICODE_ENVIRONMENT = 0x00000400,
		CREATE_SEPARATE_WOW_VDM    = 0x00000800,
		CREATE_DEFAULT_ERROR_MODE  = 0x04000000,
	}

	[StructLayout(LayoutKind.Sequential)]
		struct ProcessInfo 
	{
		public IntPtr hProcess; 
		public IntPtr hThread; 
		public uint dwProcessId; 
		public uint dwThreadId; 
	}

	[StructLayout(LayoutKind.Sequential, CharSet=CharSet.Unicode)]
		struct StartupInfo 
	{
		public int     cb; 
		public string  reserved1; 
		public string  desktop; 
		public string  title; 
		public uint    dwX; 
		public uint    dwY; 
		public uint    dwXSize; 
		public uint    dwYSize; 
		public uint    dwXCountChars; 
		public uint    dwYCountChars; 
		public uint    dwFillAttribute; 
		public uint    dwFlags; 
		public ushort  wShowWindow; 
		public short   reserved2; 
		public int     reserved3; 
		public IntPtr  hStdInput; 
		public IntPtr  hStdOutput; 
		public IntPtr  hStdError; 
	}

	[DllImport("advapi32.dll", CharSet=CharSet.Unicode, ExactSpelling=true, SetLastError=true)]
	static extern bool CreateProcessWithLogonW(
		string principal,
		string authority,
		string password,
		LogonFlags logonFlags,
		string appName,
		string cmdLine,
		CreationFlags creationFlags,
		IntPtr environmentBlock,
		string currentDirectory,
		ref StartupInfo startupInfo,
		out ProcessInfo processInfo);

	[DllImport("kernel32.dll")]
	static extern bool CloseHandle(IntPtr h);

The following is the code snippet that does the PInvoke and spawns the process under a specific user context:


                StartupInfo si = new StartupInfo();
		si.cb = Marshal.SizeOf(typeof(StartupInfo));
		si.title = "This is impersonated command prompt";

		ProcessInfo pi = new ProcessInfo();
		string app = Path.Combine(Environment.SystemDirectory, "cmd.exe");

			if (CreateProcessWithLogonW("username", "domain", "password",
			LogonFlags.LOGON_WITH_PROFILE,
			app, null,
			0, IntPtr.Zero, null,
			ref si, out pi)) 
		{
			CloseHandle(pi.hProcess);
			CloseHandle(pi.hThread);
		}
		else Console.WriteLine("Error code: {0}", Marshal.GetLastWin32Error());

ActiveSync aware - are you?

Gaurav Khanna — Tue, 14 Dec 2004 15:36:00 GMT

Ever wondered how the ActiveSync synchronization application gets launched automatically when you plug-in your SmartPhone or PocketPC? Or, would you like to build your application ActiveSync-aware, getting invoked when ActiveSync connection has been established or disconnected?

On your desktop, under the following registry key, create an entry for the application to be launched when ActiveSync connection has been established:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows CE Services\AutoStartOnConnect

Likewise, to invoke an application when ActiveSync connection is disrupted, create an entry under the following registry key:

HKLM\Software\Microsoft\Windows CE Services\AutoStartOnDisconnect

Source Code - Windows CE File Manager

Gaurav Khanna — Mon, 13 Dec 2004 22:27:00 GMT

As part of the recently concluded Mobile and Embedded DevCon 2004 at Bangalore, from 9th-11th Dec 2004, I delivered a talk on Remote API (RAPI), amongst other things. To demonstrate the tremendous power and capability of Windows CE RAPI (which allows us to managed CE based devices from the desktop), I wrote a Windows CE File Manager - a Windows Explorer like application that can be used to navigate the CE device's file system and move files to/fro the device and your desktop and open them from the device directly.

For those interested in the source code of the application, it can be downloaded from the Source Code section at the following URI:

http://www.wintoolzone.com/showpage.aspx?url=win32.aspx

Its a VS.NET 2003 VC++ Solution.