CEvent fails to signal when built on VS2013, run on Windows XP

Question

My native C++/MFC program works when compiled using VS2005 and run on 32-bit Windows XP. The same code compiled with VS2013, using the Visual Studio 2013 - Windows XP (v120_xp) platform toolset*, runs under 64-bit Windows 7, but fails on 32-bit Windows XP. I'm using the MBCS MFC library. Both builds are debug builds.

The code which fails is the signaling of an event:

// At global scope
CEvent interpHasWork(FALSE/* bInitiallyOwn*/,FALSE/*bManualReset*/,"InterpHasWork"); 

// In function A
interpHasWork.SetEvent(); // signal

// and in function B
interpHasWork.Lock(); // wait for signal

When run on the VS2013 machine (64-bit Windows 7) on which it was built, after the event is signaled in function A, function B exits the lock state (continues execution on the following line), as expected.

When the same executable is run on a Windows XP machine, after the event is signaled in function A, function B never exits the lock state.

So, the question is, how can the program be built so the executable is compatible with both OS's?

EDIT: Turns out the answer is, the thread containing function B never started, because AfxBeginThread got an error (and my pgm wasn't checking for that [BAD pgm]). Determining exactly why it was getting an error was tricky, since there is no documentation for an error return for AfxBeginThread, and CreateThread, which is what AfxBeginThread calls eventually to create the thread, is documented to use GetLastError. But GetLastError (which also isn't documented in my help files) returns 0=success. errno, however, returns 12 (not enough memory).

Because the stack reserve was set to ~500 MB, and the AfxBeginThread used the default stack size, it was also requesting a reserve of ~500 MB. All this worked when the pgm was built using VS2005, so I assume that VS2013 produces a larger executable. I reduced the worker thread's stack size to 1MB, but still got the error, so the VS2005 version must have just barely fit into XP's 2 GB user space.

* If I use the default v120 toolset, the program gives "Not a valid Win32 program" message on startup.