You can do it without the mouse, too. Just make sure the window is selected in the task bar (perhaps by using the Windows key and then tabbing to the appropraite icon), then hit Alt-Space, Alt-M, and then using the cursor keys.

The only problem is, some application developers choose to change the system menu – the menu visible from clicking the app’s icon in the top left, or by right-clicking the task bar icon – perhaps deciding for some insane reason not to include the standard Move option (as an aside, this breaks one of the fundamental tenets of usability: don’t change – or in this case, remove – existing, established behaviour). If this is the case, you can instead use a handful of lines of Windows API code to access the window and move it programatically. Here’s the entire code of a program that will do exactly that:

#include <windows.h>
#include <tchar.h>
 
int _tmain(int argc, TCHAR *argv[])
{
	if (argc < 2)
	{
		_tprintf(_T("usage: mover windowtitle\n"));
		return -1;
	}
	HWND hwnd = FindWindow(NULL, argv[1]);
	if (hwnd)
	{
		SetWindowPos(hwnd, HWND_TOP, 0, 0, 400,400, 0);
	}
	else
		_tprintf(_T("Unable to find window %s\n"), argv[1]);
	return 0;
}

Compile it up and you can use it as a handy little utility to move arbitrary top level windows, e.g. if you’ve got regedit running:

mover "Registry Editor"

The only tricky thing is finding the exact title of the window to use. Well, you wouldn’t want it to be too easy, would you?

But what happens if during the lifetime of that stack based COM object, it gets used from .NET? A runtime callable wrapper (RCW) will be created around the object. And this RCW expects to be able to keep the underlying object alive by incrementing its reference count. Of course, the stack-based object will soon go out of scope, and regardless of its reference count the object will be destroyed and the pointer that the RCW contains will no longer be valid. It points into the stack, so when the RCW gets cleaned-up, the CLR will call via this pointer into memory that contains garbage and you’ll get something nasty like an access violation or illegal instruction exception.

It’s fairly easy to reproduce this to see where things go wrong. It can be useful to see where the CLR blows up, and how we can identify this as the cause.

Lets start by creating a simple pseudo-COM object that implements just the bare minimum to be usable:

class MyClass : public IUnknown
{
public:
	MyClass():l(0) {}
	STDMETHOD_(ULONG, AddRef)() { return InterlockedIncrement(&l); }
	STDMETHOD_(ULONG, Release)() { return InterlockedDecrement(&l); }
	STDMETHOD(QueryInterface)(REFIID iid, void ** ppvObject)
	{
		if (iid == IID_IUnknown)
		{
			*ppvObject = this;
			AddRef();
                        return S_OK;
		}
		return E_NOINTERFACE;
	}
private:
	long l;
};

We’ll also need a COM visible .NET object that will use the object. It doesn’t actually need to be COM visible, but that’s the easiest way to access it from C++, in my opinion.

I’ve created the COM object in F#. It’s a trivial class that has a single interface, with a single method that takes the object we pass to it and prints its type. This is enough for the RCW to be created.

open System
open System.Runtime.InteropServices
 
module Module1 =
 
    [<ComVisible(true); InterfaceType(ComInterfaceType.InterfaceIsIUnknown)>]
    type public IConsumer = 
        abstract member UseObject : o:obj -> unit
 
    [<ComVisible(true); ClassInterface(ClassInterfaceType.None)>]
    type public Consumer() =
        interface IConsumer with
            member this.UseObject (o:obj) =
                Console.WriteLine (sprintf "%A" (o.GetType()))

We can compile this into a DLL, then run regasm with the /tlb switch to generate a type library (TLB):

fsc -o:obj\Debug\testStackObjectsFs.dll Module1.fs
regasm /tlb:testStackObjectsFs.tlb testStackObjectsFs.dll

That can be #imported back into our test harness:

#import "testStackObjectsFs.tlb"

Now we’re ready to put together some code that creates an instance of our object on the stack and passes it to our .NET component:

void Foo()
{
	// Create an instance of our "COM object" on the stack
	MyClass obj;
 
	// Create a managed object
	testStackObjectsFs::IConsumerPtr mgd(__uuidof(testStackObjectsFs::Consumer));
 
	// and pass our COM object to it
	mgd->UseObject(_variant_t(&obj));
}
 
int _tmain(int argc, _TCHAR* argv[])
{
	// Initialise the COM runtime, for our purposes it doesn't
	// matter which threading model we use
	CoInitializeEx(NULL, COINIT_MULTITHREADED);
 
	// Call a separate function, to ensure stack-based objects
	// are out-of-scope on return.
	Foo();
 
	// Wait for some input
	_getch();
	return 0;
}

Now, if you run this from within Visual Studio, if you’re vigilant (and you haven’t got your debugger set to stop on access violations), then you’ll notice this in the output window after the return statement executes:

...
The thread 'Win32 Thread' (0x15b0) has exited with code 11001 (0x2af9).
The thread 'Win32 Thread' (0x1110) has exited with code 0 (0x0).
First-chance exception at 0x00850a2b in testStackObjects.exe: 0xC0000005: Access violation reading location 0x00850a2b.
The thread 'DebuggerRCThread::ThreadProcStatic' (0x1534) has exited with code 0 (0x0).
The thread 'RPC Callback Thread' (0x12b8) has exited with code 0 (0x0).
...

Lets ramp up WinDbg, attach to the process (that _getch comes in useful here) and find out what’s going on in a bit more detail.

If we let the app run to the point of failure in WinDbg, we can see that the CLR was in the act of shutting down when it caused the exception:

0:002> kp
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00dae3fc 79f4c1b5 0xe06ff8
00dae450 79f4c26c mscorwks!ReleaseTransitionHelper+0x5f
00dae494 79f4c2d0 mscorwks!SafeReleaseHelper+0x8c
00dae4c8 79faaa01 mscorwks!SafeRelease+0x2f
00dae4fc 79faa7c8 mscorwks!IUnkEntry::Free+0x68
00dae510 79faa91d mscorwks!RCW::ReleaseAllInterfaces+0x18
00dae540 79faa949 mscorwks!RCW::ReleaseAllInterfacesCallBack+0xbd
00dae570 7a0792ac mscorwks!RCW::Cleanup+0x22
00dae57c 7a079714 mscorwks!RCWCleanupList::ReleaseRCWListRaw+0x16
00dae5ac 7a0797df mscorwks!RCWCleanupList::ReleaseRCWListInCorrectCtx+0xdf
00dae5fc 79fdc140 mscorwks!RCWCleanupList::CleanupAllWrappers+0x77
00dafe90 79fdc7aa mscorwks!RCWCache::ReleaseWrappersWorker+0x103
00dafed8 79fd9f95 mscorwks!ReleaseRCWsInCaches+0x27
00dafee0 79f3c76a mscorwks!InnerCoEEShutDownCOM+0x1e
00daff14 79f92015 mscorwks!WKS::GCHeap::FinalizerThreadStart+0x1fc
00daffb4 7c80b683 mscorwks!Thread::intermediateThreadProc+0x49
00daffec 00000000 kernel32!BaseThreadStart+0x37

Essentially it’s cleaning up the currently unused RCWs – including our malformed one – and as part of doing this, it’s calling Release on the underlying COM object, via the mscorwks!SafeRelease function. SafeRelease wraps the call to potentially (and definitely, in this case) dangerous unmanaged code with various exception handlers, enabling it to silently handle access violations.

If we run the app again, and this time break while it’s waiting for the keypress, before it attempts to clean up the RCWs, then we can examine the wrapper ourselves, using the approach I set out in this post.

List all of the untyped COM object wrappers:

0:002> !dumpheap -type System.__ComObject
 Address       MT     Size
01418628 79306e60       16
total 1 objects
Statistics:
      MT    Count    TotalSize Class Name
79306e60        1           16 System.__ComObject
Total 1 objects

Use the address of the object to obtain its object header:

0:002> dd 1418628-4 L1
01418624 08000002

Use the syncblk identifier in the header to get the syncblk:

0:002> !syncblk 2
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
    2 001e4d9c            0         0 00000000     none    01418628 System.__ComObject
-----------------------------
Total           2
CCW             0
RCW             0
ComClassFactory 0
Free            0

Get the address of the RCW from the sync block:

0:008> dd 001e4d9c+1c L1
001e4db8 001e7dc8
0:008> dd 001e7dc8+c L1
001e7dd4 001de828

And dump out the relevant bits of the RCW, the vtable of the object, at offset 0×88, and the IUnknown pointer, at offset 0×64:

0:008> dds 001de828+88 L1
001de8b0 0041ac78 testStackObjects!MyClass::`vftable'
0:008> dds 001de828+64 L1
001de88c 0012fe7c

We can use !address to do a quick sanity check on the pointer and verify what we know to be the case; it’s stack memory:

0:008> !address 0012fe7c
    00030000 : 00124000 - 0000c000
                    Type     00020000 MEM_PRIVATE
                    Protect  00000004 PAGE_READWRITE
                    State    00001000 MEM_COMMIT
                    Usage    RegionUsageStack
                    Pid.Tid  490.13dc

If we run the app on again to the point that it fails, we can clearly see the address of the object being passed as an argument to mscorwks!IUnkEntry::Free.

So the moral of the story is; don’t pretend some arbitrary piece of stack memory is a real, reference counted COM object. You may be saving the cost of a heap allocation, but even if your app works OK today, it may not tomorrow when someone introduces a piece of .NET code somewhere in your object graph.

Bonus Extra Content

As a bonus tip, here are a couple of WinDbg breakpoints that can be used to dump each RCW as it’s created and destroyed.

bu 79faa974 "dds @ecx L23; g"
bu 79faa538 "dd @esp+20 L1; dds poi(@esp+20)+88 L1; g"


This is such a common source of bugs, and such an important requirement, that from Vista onwards Microsoft introduced a new set of functions in the Windows API explicitly to support it: One-Time Initialization.

And even if you get away with doing naughty things in DllMain now, don’t think that it’ll stay that way forever. We got away with it for years, then when .NET came along it introduced all sorts of additional correctness checks. For instance, the Managed Debugging Assistant (MDA) in Visual Studio will shout loudly should you attempt to run managed code during DllMain.

Managed Debugging Assistant 'LoaderLock' has detected a problem in 'C:\YourApp.vshost.exe'.
Additional Information: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

And it’s easier than you think to do so. For example, calling something as innocuous as GetWindowText can result in managed code being run.

How can you get around this?

One of the approaches I’ve used has been to make use of Win32 asynchronous procedure calls. Specifically you can call QueueUserAPC to add a function to the queue, and this can contain the initialisation you would’ve otherwise done in DllMain.

However there is significant gotcha regarding use of APCs: your function will not be called until the thread is in an “alertable wait state”. This means you (or some other code on the thread) need to call an alertable wait function such as SleepEx, WaitForSingleObjectEx and specify TRUE for the alertable parameter.

Once your APC is getting called successfully you’ll be in much better place; your code will be executed outside of the scope of the dreaded OS loader lock and you’ll be doing things by the book, hopefully avoiding all the potential pitfalls that lie in wait within DllMain.

1. Exclamation marks in dialog box messages
Look, it’s probably the 50th time I’ve seen this message today. The fact that this application “Cannot connect to database!” is no longer a surprise. You may have noticed that most professional software uses a neutral tone for its communication with the user. Try that. Also:
1a. Double negatives in confirmation dialogs
“Are you sure you don’t want to lose your changes?” Err… what? No. I mean YES. Oh sh*t. Any dialog that requires you to stop and try to parse the question in order to work out if you’re about to destroy several hours of work is not doing its job. It’s getting in the way of you doing your job. In fact, convoluted messages are such a serious issue that Microsoft even tried to help developers to help their users by introducing a whole new kind of dialog box in Vista: the question/task dialog. Good luck with that.

2. No tab ordering defined\mouse only navigation
Because no-one’s ever going to use the keyboard to navigate the zillion controls in your data entry app, are they? This one actually surprises me, because I’d have thought that developers would’ve needed to navigate quickly through the application while they’re writing it. Well, that doesn’t seem to be the case. Pretty much all commercial apps are good counter examples. I don’t mean to hold up Microsoft Office as a paragon of UI virtue, but they definitely do the “alternate way of navigating everything” thing well. Everything you need can be reached by both keyboard and mouse. Unplug your mouse and try that with your favourite piece of in-house software and see how you get on.

3. Group boxes around everything
This is a bit of a WinForms specific one. The clue is in the name: group boxes are for grouping logically related controls, not for providing a kewl recessed border around every single one of the controls in your dialog. Don’t kid yourself that this is doing anything other than using up some valuable screen real estate. (See if you can spot another pet peeve in the example dialog, too).

4. Icons created in the IDE
Look, Visual Studio’s a really good integrated development environment, but it ain’t no Photoshop. Don’t try and use it to create icons. And while you’re at it, please don’t make icons consisting solely of the name of your application (inevitably an acronym) in pixel font and primary colours. Oh, and don’t just steal various icons from another application, unless you’re going to steal the whole lot; one of the key visual aspects of a good UI is consistency. Mixing your hand-drawn 4-bit icons with the glorious 32-bit shiny ones you borrowed is going to be jarring. In fact, why not go the whole way and get someone who can actually draw to create your icons for you? After all, you wouldn’t have someone who wasn’t a programmer writing the code, would you…?

5. Data grids
Otherwise known as the “Excel is the pinnacle of user interface design” disease. Break the habit. Generally, the more types of controls that are embedded in your grid, the less likely that it’s the right kind of interface paradigm. Yeah, I’m looking at you, person embedding a calendar control, drop down box, graph, slider and checkbox in each row of a data grid. And whatever your 3rd-party grid provider of choice says, it’s not going to do screen redraw performance any good, either.

6. Not implemented message boxes
Ahh, the GUI equivalent of source code TODO comments. Of course, it’s an in-house software give-away; no commercial (desktop) software would be brazen enough to ship with bits of functionality dangling from the stumps of buttons and menu items. Would it? Feel free to provide counter-examples if you have them.

7. Excessive use of dialog boxes
Warning: dialog boxes are considered harmful (to usability). They’re the equivalent of restraining your user by force and preventing her from moving until she answers your question. That might be OK for matters of life or death (i.e. data loss), but not otherwise. Every time you find yourself about to add a new message box, stop, take a deep breath and consider whether it’s really necessary.

So, if you’re a victim or one, many, or all of these user interface faux pas, all I can say is: sorry. I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins.

It’s obvious looking at the output from VMmap or windbg’s !address command what the largest contiguous block is, e.g.

0:008> !address -summary
....
Largest free region: Base 07300000 - Size 63ed0000 (1637184 KB)

But what if you need that number in order to make a decision at run-time? For instance, to decide whether your process is in a fit state to continue, or if it should instead commit hara-kiri. In that case, you need to access the information programmatically. That’s where the immensely useful VirtualQueryEx function comes in…

VirtualQueryEx gives you information on a single page of your virtual address space at a time. Pages size are dependent on the architecture and OS, but if you just want to iterate over all of them, you don’t need to add any special handling; the function returns the size of the page in an element of the MEMORY_BASIC_INFORMATION structure, so you can simply move to the ‘next’ page regardless of size.

If you’re interested in free space, you’ll need to find all the pages that have a state of MEM_FREE (0×10000), and that’s pretty much all there is to it. By keeping track of how much space falls into a continuous range of MEM_FREE pages you can get to the number reported by VMmap and !address.

Here’s some C++ code that returns the address of the largest free contiguous block in largestFreestartlargestFree. Enjoy!

	MEMORY_BASIC_INFORMATION mbi;
	DWORD start = 0;
	bool recording = false;
	DWORD freestart = 0, largestFreestart = 0;
	__int64 free = 0, largestFree = 0;
	while (true)
	{
		SIZE_T s = VirtualQueryEx(hproc, reinterpret_cast<lpvoid>(start), &mbi, sizeof(mbi));
		if (s != sizeof(mbi))
		{
			if (GetLastError() != ERROR_INVALID_PARAMETER)
				return ReportError(GetLastError(), _T("Failed to VirtualQueryEx at %08x"), start);
			else
				break;
		}
		if (mbi.State == MEM_FREE)
		{
			if (!recording)
				freestart = start;
			free += mbi.RegionSize;
			recording = true;
		}
		else
		{
			if (recording)
			{
				if (free > largestFree)
				{
					largestFree = free;
					largestFreestart = freestart;
				}
			}
			free = 0;
			recording = false;
		}
		start += mbi.RegionSize;
	}

(I had problems with WordPress choking on this long post, so I’ve split it into 2 parts. This the first part, the second part is here).

First things first: you can download it from here.

Using VMMap

VMMap graphically displays the contents of your processes’ virtual memory, which each type of memory colour coded. This means you can quickly get an idea of how all of your valuable 2GB address space is being used.

At this point it’s worth pointing out that this article refers to the 32 bit Windows XP platform only, as that’s what I use on a day-to-day basis. Moving to a 64 bit address space makes it so large that exhaustion of a process’ address space is pretty damn unlikely, discounting your application doing something pathological.

VMMap top pane

The number in the bottom left in the largest free block of address space. It’s the same number as reported by !address -summary in WinDbg. See the post here if you want to calculate it programmatically. If this number is small (less than 64MB) you’ll probably have out of memory issues, see below for more details.

Note: Generally the working set size is NOT the important number here; it’s a common mistake that people make when looking at memory usage figures in something like Task Manager. The working set size is merely an indication of the amount of virtual memory that has recently been accessed and it’s entirely possible to make the WS size number plummet by explicitly “flushing” the working set. You can do this by, for example, minimising a GUI application. As such, this is really not the number you want to be tracking. Instead, look at the Private Bytes or Virtual Memory Size counter in perfmon.

But back to VMMap. There are various different types of allocation reported. I’ll describe some of the most interesting ones:

Image

A DLL or other executable file, as typically loaded by LoadLibraryEx. You’ll see the protection is Execute/Copy on Write; this is the standard for executables, where the OS will share the memory between processes unless they modify it – which is very rare.

You may also see the same file loaded as a mapped image. For instance, when using a COM server that contains an embedded type library resource, it will be loaded in both ways; once as an executable using LoadLibrary and once as a mapped file using LoadTypeLib. You may also notice that non-ngen’d .NET images are mapped twice. This appears to be a bug that Microsoft are aware of, there’s a bug logged in Connect for it.

You can expand the image entry to see the size of the image sections, the file header, code (.text), resources (.rsrc) and relocations (.reloc) for example.

Mapped file

These are typically data files loaded using CreateFileMapping. Depending on how the mapping was created (whether an explicit maximum size was specified), either the whole of the file or some small section of it will be mapped. Of course, the whole point of memory mapped files is to be able to get access to sections of a file without having to load it all, so the chances are that only small files will be mapped in their entirety.

Memory mapped files are often used to share data between processes, so you may find that things put on the clipboard may appear as mapped address space, albeit transiently. This is especially obvious in Microsoft Office apps like Excel.

Heaps

This is the meta-data associated with each heap in the process. The actual allocations from the heap are stored separately in the address space (more on that later, see Private Data).

Some people are surprised that there can be multiple heaps in a single process, but it’s actually quite common practice in unmanaged code, especially where there are specific memory management requirements. MSXML is a widely used example of this; it does it’s own garbage collection using it’s own dedicated heaps.

There is always a default heap created by the loader during process creation, and others are created explicitly using HeapCreate. The address of the heap displayed by VMMap can be used with the WinDbg !heap command to delve more deeply into it’s contents and structure. For instance, !heap -m will display it’s segment details.

Managed heap

Obviously this is only relevant for applications using .NET – managed apps themselves or unmanaged apps that implicitly load .NET assemblies in some other way, say, via COM. The number displayed is the sum of the generation 0, 1, 2 and large object heap sizes.

Thread stack

Each thread in the OS has a stack that can grow to 1MB by default (although this is configurable at link time, and controllable programmatically). It starts as a block of uncommitted reserved memory, with the used space committed at the bottom, and a guard block that is used to determine when to expand the block downwards. VMMap helpfully displays the thread ID in the stack space row.

Remember that each thread will have it’s own stack space, so spinning up threads is not free in terms of virtual memory use. See here for more details on thread stack space.

Read on here for more…

Like most of my posts, this assumes that it’s not feasible to go through all your source code, and say, replace all instances of new with a version that tracks usage (the approach used by the debug CRT). As well as being logistically infeasible, this also tends to miss allocations that don’t go via new, for example, direct calls to HeapAlloc.

In the past, I’ve seen some code trying to use the Win32 heap functions to try and find out the amount of memory allocated by the process. It used GetProcessHeaps, HeapWalk and HeapSize to sum all the block sizes and get an overall memory in use figure, but in my experience it was extremely slow and unreliable.

What was really required was something that gave a figure similar to the “private bytes” counter in perfmon. If you didn’t know, this is the counter you need to be watching if you’re looking for memory leaks in a process. For goodness sake don’t use the “Mem Usage” column in Task Manager; this is in fact (almost) the working set size and it doesn’t correlate exactly with memory explicitly allocated by the process. It includes additional things including space occupied by the loaded DLLs. Also, the working set will shrink if the app is paged out, although it still has the memory allocated. To see an example of this in action, open Excel and a large spreadsheet, calc it, look in Task manager and you’ll see a large number (if not, you’re obviously not looking at a real spreadsheet). Then minimise the Excel window. You’ll see the mem usage value plummet as the working set is ”trimmed” – probably by a call to SetProcessWorkingSetSize. The OS does this because it expects the app won’t be being used, so it makes sense to free up physical memory for use by other processes.

So essentially what I want to do is get the perfmon “private bytes” value programmatically as my app is running, and this can be achieved using the Performance Data Helper (PDH) library. It provides an API to access the performance counters in a similar way to the perfmon GUI.

It uses the concept of “queries”; you create a query, add a counter to it, then collect the query data as required (not forgetting to remove the counter and close the query when you’re done).

The first thing to do is open the query:

Then add the required counters (this code assumes you’re looking at a process on the current machine):

At this point you’re ready to start polling for updates. At periodic intervals you can collect the query data and do with it what you will:

Luckily for the Private Bytes counter we’ve got the simplest type of counter to ‘decode’; a raw counter value, essentially just a number. We don’t need to do any further manipulation on it to get the information we need, like having to divide by some frequency.