So you got a memory corruption issue with a piece of software. It comes in a unique scenario along the line of having a huge pile of weird code running well most of the time and then, right out of the blue, a corruption takes place followed by unexpected code execution and unstable software state in general.

The biggest problem with memory corruption is that a fragment of code is modifying a memory block which it does not own, and it has no idea who actually is the owner of the block, while the real owner has no timely way to detect the modification. You only face the consequences being unable to capture the modification moment in first place.

To get back to the original cause, an engineer has to drop into a time machine, turn back time and step back to where the trouble took originally place. As developers are not actually given state-of-the-art time machines, the time turning step is speculative.

CVirtualHeapPtr Class: Memory with Exception-on-Write access mode

At the same time a Windows platform developer is or might be aware of virtual memory API which among other things provides user mode application with capabilities to define memory protection modes. Having this on hands opens unique opportunity to apply read-only protection (PAGE_READONLY) onto a memory block and have exception raised at the very moment of unexpected memory modification, having call stack showing up a source of the problem. I refer to this mode of operation as “hardware assisted” because the access violation exception/condition would be generated purely in hardware without any need to additionally do any address comparison in code.

Needless to say that this way is completely convenient for the developer as he does not need to patch the monstrous application all around in order to compare access addresses against read-only fragment. Instead, a block defined as read-only will be immediately available as such for the whole process almost without any performance overhead.

As ATL provides a set of memory allocator templates (CHeapPtr for heap backed memory blocks, allocated with CCRTAllocator, alternate options include CComHeapPtr with CComAllocator wrapping CoTaskMemAlloc/CoTaskMemFree API), let us make an alternate allocator option that mimic well-known class interface and would facilitate corruption detection.

Because virtual memory allocation unit is a page, and protection mode is defined for the whole page, this would be the allocation granularity. For a single allocated byte we would need to request SYSTEM_INFO::dwPageSize bytes of virtual memory. Unlike normal memory heap manager, we have no way to share pages between allocations as we would be unable to effectively apply protection modes. This would definitely increase application pressure onto virtual memory, but is still acceptable for the sacred task of troubleshooting.

We define a CVirtualAllocator class to be compatible with ATL’s CCRTAllocator, however based on VirtualAlloc/VirtualFree API. The smart pointer class over memory pointer would be defined as follows:

template <typename T>
class CVirtualHeapPtr :
    public CHeapPtr<T, CVirtualAllocator>
{
public:
// CVirtualHeapPtr
    CVirtualHeapPtr() throw();
    explicit CVirtualHeapPtr(_In_ T* pData) throw();
    VOID SetProtection(DWORD nProtection)
    {
        // TODO: ...
    }
};

The SetProtection method is to define memory protection for the memory block. Full code for the classes is available on Trac here (lines 9-132):

• CGlobalVirtualAllocator class is a singleton querying operating system for virtual memory page size, and provides alignment method
• CVirtualAllocator class is a CCRTAllocator-compatible allocator class
• CVirtualHeapPtr class is smart template class wrapping a pointer to allocated memory

Use case code will be as follows. “SetProtection(PAGE_READONLY)” enables protection on memory block and turns on exception generation at the moment memory block modification attempt. “SetProtection(PAGE_READWRITE)” would restore normal mode of memory operation.

CVirtualHeapPtr<BYTE> p;
p.Allocate(2);
p[1] = 0x01;
p.SetProtection(PAGE_READONLY);
// NOTE: Compile with /EHa on order to catch the exception
_ATLTRY
{
    p[1] = 0x02;
    // NOTE: We never reach here due to exception
}
_ATLCATCHALL()
{
    // NOTE: Catching the access violation for now to be able to continue execution
}
p.SetProtection(PAGE_READWRITE);
p[1] = 0x03;

Given the information what data gets corrupt, the pointer allocator provides an efficient opportunity to detect the violation attempt. The only thing remained is to keep memory read-only, and temporarily revert to write access when the “legal” memory modification code is about to be executed.

One-shot Read/Write Protection with Guard Pages

Another option granted by memory protection modes is brought by PAGE_GUARD flag. MSDN says:

A guard page provides a one-shot alarm for memory page access. This can be useful for an application that needs to monitor the growth of large dynamic data structures. For example, there are operating systems that use guard pages to implement automatic stack checking.

Setting a guard page mode provides an additional option to trigger an exception with even read access to a protected memory block.

p.SetProtection(PAGE_READWRITE | PAGE_GUARD);
BYTE n = p[0];

CDebugHeapPtr Class: More Options to Catch Memory Corruption Conditions

While setting memory protection attributes on a memory block of interest provides unique troubleshooting opportunities, it still does not cover important typical problems with memory misuse scenarios. Those are writing immediately before the allocated block, and writing immediately after. Having array of N items, this would be writing to indices -1 and N respectively.

To address this scenarios of misuse we can extend CVirtualHeapPtr class so that it could additionally provide “sanity pages” with PAGE_NOACCESS protection at the boundary of allocation. Because virtual memory allocation is granular, we will have to have padding bytes that extend our block to the page boundary, however we have an option to put the padding bytes before or after the payload data block in order to capture after or before memory block writes respectively.

The figure below shows memory layout for the data:

Source code for the CDebugHeapPtr class is available on Trac (lines 155-). The sanity pages create a block of inaccessible addresses which immediately cause access violation exception on either read of write access attempt. Under debugger, those are shows with question marks:

The padding space is pre-initialized with hardcoded value 0×77, and the space is checked for integrity at release of memory block call.

Catching the Exceptions

Having the exceptions generated on run-time, they immediately alter application execution code path and are easy to track and catch. There is no need to bring the feature rich debugger, such as Visual Studio to the production site in order to catch the exception and environment, instead a way simpler tool such as LogProcessExceptions would be able to create a minidump file and write the state of the application. The minidump can be transferred into debugger-enabled environment for detailed check.

Visual C++ .NET 2010 source code is available from SVN.

This adds a small update to the recently published GPS Location/Coordinate Converter utility:

• Seconds in Degrees, Minutes & Seconds notation are shown and are accepted as floating point numbers
• More shortcuts to popular online map services (note that only Google Maps and Yandex Maps are still accepted as input via clipboard):
• Bing Maps
• Yahoo Maps
• Open Street Map
• WikiMapia

The latter makes the tool an easy to use converted between the services for a GPS POI.

A binary [Win32] and partial Visual C++ .NET 2010 partial source code are available from SVN.

A colleague pointed out that code snippet in previous post is misusing ATL’s ATLENSURE_SUCCEEDED macro making it [possibly] evaluate its argument twice in case of failure, that is evaluating into failure HRESULT code. As it is defined like this:

#define ATLENSURE_SUCCEEDED(hr) ATLENSURE_THROW(SUCCEEDED(hr), hr)

It does things in a straightforward way, for a code line

ATLENSURE_SUCCEEDED(pFilterGraph.CoCreateInstance(CLSID_FilterGraph));

It is doing “let’s CoCreateInstance the thing and if it fails, let’s CoCreateInstance it again to find out error code”. Disassembly shows this clearly:

This is exactly another spin of the story previously happened with HRESULT_FROM_WIN32 macro and possibly a number of others. With it being originally a macro, SDK offered an option to override the definition by pre-defining INLINE_HRESULT_FROM_WIN32. This way a user might be explicitly requesting a safer definition while still leaving legacy code live with macro. See more detailed story on this in Matthew’s blog.

A tricky thing is that with successful execution the problem does not come up. In case of failure, it depends on the functions called, some with just repeat the error code, some will return a different code on second run, some might create less desired and expected consequences. So you can find yourself having written quite some code before you even suspect a problem.

Having identified the issue, there are a few solutions.

1. First of all, the original ATLENSURE_SUCCEEDED macro can still be used, provided that you don’t put expressions as arguments.

This is going to do just fine:

const HRESULT nCoCreateInstanceResult = pFilterGraph.CoCreateInstance(CLSID_FilterGraph);
ATLENSURE_SUCCEEDED(nCoCreateInstanceResult);

2. Second straightforward way is to replace the original ATL definition in ATL code (boo, woodenly)

3. As ATL code is checking for the macros to be already defined, and skipping its own definition in such case, it is possible to inject a safer private definition before including ATL headers (which would typically need one to do the define in stdafx.h):

#define ATLENSURE_SUCCEEDED(x){ const HRESULT nResult =(x); ATLENSURE_THROW(SUCCEEDED(nResult), nResult); }

#include <atlbase.h>
#include <atlstr.h>

Pre-evaluating the argument into local variable is going to resolve the original multi-evaluation problem.

4. There might be a new inline function defined on top of the original macro, which will be used instead and which is free from the problem:

inline VOID ATLENSURE_INLINE_SUCCEEDED(HRESULT nResult)
{
    ATLENSURE_SUCCEEDED(nResult);
}

Either way, the correct code compiles into single argument evaluation and throws an exception with failure code immediately:

Also, vote for the suggestion on Microsoft Connect. The issue is marked as fixed in future version of Visual Studio.

An updated version of LogProcessExceptions utility is given an additional option to create minidump .DMP files for debugged process on user request. This is in particular useful in conjunction with flag choices (on the previous page of the wizard).

Partial Visual C++ .NET 2010 source code is available from SVN, release binary included (Win32, x64).

LogProcessExceptions utility implements a very basic debugger which attaches (see DebugActiveProcess on MSDN) to a running process and monitors its exceptions. Once exception takes place the utility creates a minidump file for the process (see MiniDumpWriteDump on MSDN) so that exception condition could be investigated off-site using debugger.

If you throw C++ exceptions in your C++ code in exceptional cases which indicate necessity to log the condition and possibly check it later, the utility will get the vital information for the application running at production location in environment without fully featured debugger (note that the utility is a simple download-and-run “wizard” style application, with no installation required), or will simply track the error letting the application continue execution without pretty much of an interruption.

The tool will prompt for debuggee process, and follow with minidump type choices and the debugging operation.

Minidump files are created automatically with the name file including:

• Excecutable Name
• Process Identifier
• Ordinal Number
• Exception Code
• C++/ATL Exception HRESULT Code (esp. for CAtlException exceptions)

The utility is expected to work with Windows XP operating system and more recent.

Partial Visual C++ .NET 2010 source code is available from SVN, release binary included (Win32, x64).

Artwork credits: http://cristoildiablo.deviantart.com/

If you dare to convert your C++ ATL Service project created with an earlier version of Visual Studio to version 2010, as I recently did, you might find yourself surprised with why the hell the bloody thing does not work anymore as a regular executable.

After passing compiler/linker and SDK update issues, which you possibly might have too, the started executable will stumble on ATL error/exception with CO_E_NOTINITIALIZED (0x800401F0 “CoInitialize has not been called.”). Luckily the error code is good enough for quickly locating the problem and the reason is that the one you trusted, that is ATL, introduced an small improvement which is good for running as service but it not initializing COM anymore if you run your .EXE in application mode.

The bug is on MS Connect since August 3, 2010 closed as if it is going to be fixed some time in future when the fix is propagated to end developers. If you are in a rush and would like to write some code before the event, here are the details.

Previously, COM was initialized right in module constructor, in CAtlExeModuleT. CAtlServiceModuleT class just inherited from there. Later on, someone smart decided that it was not so cool and moved initialization to a later point into CAtlExeModuleT::WinMain. Well, this makes sense as you might (a) end up not needing COM at all, or (b) you want to do some important things before even initializing COM.

Unfortunately, the fact that CAtlServiceModuleT is inherited and relies on base class was not paid too much attention. CAtlServiceModuleT is not getting COM initialization from constructor any longer, CAtlServiceModuleT::WinMain is overridden in full and does not receive initialization from new location either. So well, it does not receive it at all unless run as service, which code execution branch looks still heatlhy here and exhibits another issue later soon.

To resolve the problem, the fragment in CAtlServiceModuleT::Start needs the correction as shown below (within #pragma region):

        if (::StartServiceCtrlDispatcher(st) == 0)
                m_status.dwWin32ExitCode = GetLastError();
            return m_status.dwWin32ExitCode;
        }

        // local server - call Run() directly, rather than
        // from ServiceMain()
        #pragma region Run wrapped by InitializeCom/UninitializeCom
        // FIX: See http://connect.microsoft.com/VisualStudio/feedback/details/582774/catlservicemodulet-winmain-coinitialize-not-called-800401f0
#ifndef _ATL_NO_COM_SUPPORT
        HRESULT hr = E_FAIL;
        hr = T::InitializeCom();
        if (FAILED(hr))
        {
            // Ignore RPC_E_CHANGED_MODE if CLR is loaded. Error is due to CLR initializing
            // COM and InitializeCOM trying to initialize COM with different flags.
            if (hr != RPC_E_CHANGED_MODE || GetModuleHandle(_T("Mscoree.dll")) == NULL)
                return hr;
        } else
            m_bComInitialized = true;
        m_status.dwWin32ExitCode = pT->Run(nShowCmd);
        if (m_bComInitialized)
            T::UninitializeCom();
#else
        m_status.dwWin32ExitCode = pT->Run(nShowCmd);
#endif
        #pragma endregion 

        return m_status.dwWin32ExitCode;
    }

Going further from there, the introduced optimization also removed COM initialization from main process thread module Run function. Provided there earlier too through module constructor it is not longer there. So if you are doing something in application’s run when the application is set to run as service and is executed in application (where you might want to start application as a sort of a helper, or otherwise in specific mode), you need COM initialization there too.

It might be something like this:

class CFooModule :
    public CAtlServiceModuleT<CFooModule>
{
// [...]
    HRESULT Run(INT nShowCommand = SW_HIDE) throw()
    {
// [...]
            if(m_bServiceHelper)
            {
                // NOTE: Starting with Visual Studio 2010 service helper's Run receives no automatic COM initialization any longer
                nResult = InitializeCom();
                if(SUCCEEDED(nResult))
                {
                    nResult = __super::Run(nShowCommand);
                    UninitializeCom();
                }
            } else
                nResult = __super::Run(nShowCommand);
// [...]
    }
// [...]
};

Having done that we are really closer but there is still another breaking bug in ATL caused by Visual Studio 2010 changes. You start a service and its endlessly shown as being started.

It appears that ATL is failing to call SetServiceStatus(SERVICE_RUNNING) to indicated startup completion and service healthy state. Again, the bug is related to change in base class behavior. This time, the problem is caused by the fact that SetServiceStatus call was moved from CAtlServiceModuleT::Run into CAtlServiceModuleT::PreMessageLoop. However, it was moved into the section conditionally compiled with definition of _ATL_FREE_THREADED. If you are and old school guy with _ATL_APARTMENT_THREADED instead and is just converting and older project that worked before, you have a problem here again: you have to add missing call.

To fix this, the end of CAtlServiceModuleT::PreMessageLoop should be looking like this:

#else
        hr = CAtlExeModuleT<T>::PreMessageLoop(nShowCmd);

        #pragma region Missing SetServiceStatus
        if (m_bService)
        {
            LogEvent(_T("Service started/resumed"));
            SetServiceStatus(SERVICE_RUNNING);
        }
        #pragma endregion 
#endif // _ATL_FREE_THREADED

#endif    // _ATL_NO_COM_SUPPORT

        ATLASSERT(SUCCEEDED(hr));
        return hr;

Well, this is embarrassing.

RasterizeFont utility takes a font on the input (such as Windows .TTF – True-Type Font) and paints individual characters into bitmaps. Utility output includes separate bitmap (.BMP) files for requested characters and C++ source code of the bimap arrays (this was included into microcontroller project).

A configuration .INI file defines rasterizer parameters:

[General]
Width=48
Height=72
Horizontal Adjustment=1
Vertical Adjustment=0
Outline=1

[Font]
Face=Times New Roman
Height=48
Weight=1024

[Bitmaps]
PathTemplate=Character-%04x.bmp

And a list of characters of interest is passed as a command line argument.

const BYTE pnCharacter007a[] = // 0x007a z
{
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x54, 0x00, 0x05,  // 01 01 01 00 00 00 00 00 00 00 01 01 
    0x52, 0xaa, 0xa1,  // 01 01 00 10 10 10 10 10 10 10 00 01 
    0x52, 0x00, 0xa1,  // 01 01 00 10 00 00 00 00 10 10 00 01 
    0x54, 0x42, 0x85,  // 01 01 01 00 01 00 00 10 10 00 01 01 
    0x55, 0x2a, 0x15,  // 01 01 01 01 00 10 10 10 00 01 01 01 
    0x54, 0xa0, 0x45,  // 01 01 01 00 10 10 00 00 01 00 01 01 
    0x52, 0x80, 0x21,  // 01 01 00 10 10 00 00 00 00 10 00 01 
    0x52, 0xaa, 0xa1,  // 01 01 00 10 10 10 10 10 10 10 00 01 
    0x54, 0x00, 0x05,  // 01 01 01 00 00 00 00 00 00 00 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
    0x55, 0x55, 0x55,  // 01 01 01 01 01 01 01 01 01 01 01 01 
};

A binary [Win32] and Visual C++ .NET 2008 source code are available from SVN.

ExportAviResources walks through AVI video clips attached as resources to a binary file and exports them into separate files.

Such clips can be used with Animation Controls for GUI animations. You might want to run the utility against SYSTEM32/SYSWOW64 folders to see if any of stock animations are good for you:

D:\>for %i in (C:\Windows\system32\*.dll) do "..\Utilities\ExportAviResources\x64\Release\ExportAviResources.exe" "%i"

A binary [Win32, x64] and Visual C++ .NET 2010 source code are available from SVN.

LogicalProcessorInformation is a fronend GUI around GetLogicalProcessorInformation API and reveals CPU configuration of the system. If you are fine tuning stuff, you might want to know what sort of CPUs are powering the applications:

• how many?
• fully featured cores or HyperThreading technology?
• mutli-processor configuration and how exactly physical processors are distributed over affinity mask

API and the application gets you the data as a user-friendly dump of GetLogicalProcessorInformation output and a summary of records at the bottom:

Logical Processors:

Mask: 0x00000003
Relationship: RelationProcessorCore (0x0)
ProcessorCore.Flags: 0x01

Mask: 0x00000003
Relationship: RelationCache (0x2)
Cache.Level: 1
Cache.Associativity: 8
Cache.LineSize: 64 (0x40)
Cache.Size: 32768 (0x8000)
Cache.Type: CacheData (0x2)

Mask: 0x00000003
Relationship: RelationCache (0x2)
Cache.Level: 1
Cache.Associativity: 4
Cache.LineSize: 64 (0x40)
Cache.Size: 32768 (0x8000)
Cache.Type: CacheInstruction (0x1)

Mask: 0x00000003
Relationship: RelationCache (0x2)
Cache.Level: 2
Cache.Associativity: 8
Cache.LineSize: 64 (0x40)
Cache.Size: 262144 (0x40000)
Cache.Type: CacheUnified (0x0)

Mask: 0x0000000c
Relationship: RelationProcessorCore (0x0)
ProcessorCore.Flags: 0x01

...

Mask: 0x000000ff
Relationship: RelationProcessorPackage (0x3)

...

Mask: 0x000000ff
Relationship: RelationNumaNode (0x1)
NumaNode.NodeNumber: 0x0

Record Count per Relationship:
 RelationProcessorCore (0x0): 4
 RelationNumaNode (0x1): 1
 RelationCache (0x2): 13
 RelationProcessorPackage (0x3): 1
 RelationGroup (0x4): 0

A binary [Win32, x64] and Visual C++ .NET 2010 source code are available from SVN.

Windows Vista introduced new synchronization API: slim reader/writer (SRW) locks. Being already armed with critical sections, one perhaps would not desperately need an SRW lock, but still it offers a great option to provide both exclusive (critical section alike) mode and shared mode when 2+ threads can enter protected section simultaneously. Some time earlier, I already touched SRW lock recursion issue.

This time it is more about performance. Let us suppose we have a code fragment:

static const SIZE_T g_nCount = 100000000;
for(SIZE_T nIndex = 0; nIndex < g_nCount; nIndex++)
{
    AcquireSRWLockShared(&m_Lock);
    ReleaseSRWLockShared(&m_Lock);
}

How fast is this? Provided that execution took 1.6 ms on an idle lock variable, how fast it is going to be with another shared “reader” on another thread who acquired once access in shared mode? This part comes up confusing: it appears almost twice as slow: 2.9 ms, with also a number of contentions (and context switches) on the way.

SRW lock is advertised as lightweight and fast API, no recursion, no extra features, no fool proof checks. So it could be assumed to get you top performance, but 50 lines of code class can definitely outperform it.

A perhaps simplest SRW lock can be backed on a LONG (or LONGLONG) volatile variable accessed with interlocked API functions. The rules are simple:

• initial value of zero means idle state
• shared “reader” enters incrementing by one, positive values indicates one ore more readers
• exclusive “writer” enters decrementing by a hundred (well, this needs to be any value big enough to be less than minus maximal amount of simultaneous concurrent readers)
• releasing acquired state the value is decremented (incremented) back
• in case of contention thread yields execution to continue later with possibly better luck with shared resource (option: implement spic count for several attempts in a row, which is better suitable for multi-processor systems)

It is clear that concurrent readers touch value only once with a single increment only, leaving no opportunity to yield execution due to contention. How fast it can be?

static const SIZE_T g_nCount = 100000000;
for(SIZE_T nIndex = 0; nIndex < g_nCount; nIndex++)
{
    while(InterlockedIncrement(&m_nNativeLock) < 0)
    {
        InterlockedDecrement(&m_nNativeLock);
        SwitchToThread();
    }
    InterlockedDecrement(&m_nNativeLock);
}

It is 1.3 ms regardless whether there are any shared readers on concurrent threads. It appears that a simple custom SRW lock class is going to be superior to the API:

• faster due to zero API overhead (inline compiled code versus WINAPI convention functions)
• faster in shared mode due to not being subject to additional overhead and contentions
• flexible spin counts possible to tune performance for specific use
• extensibility:
  • recursion is allowed shared mode
  • easy to implement upgrades and downgrades between shared and exclusive modes

Sample code is Visual Studio 2010 C++ project accessible from SVN repository.

Update: Critical Section Test. This is how SRW lock API performance compares to entry/leaving critical section (provided that critical section is never locked at entry time). Critical section is about 15% slower to enter and leave.

C:\Projects\...\SrwLockTest02\x64\Release>SrwLockTest02.exe
API: 100M iterations, 1575 ms
API: 100M iterations, 2839 ms
Native: 100M iterations, 1311 ms
Native: 100M iterations, 1326 ms
Critical Section: 100M iterations, 1841 ms