Standalone Windows app hangs upon change of focus - c++

Question

I have written an app in C++ from Visual Studio 2008, running on Windows 7, that runs fine, using either the debug or release versions, when under the control of the debugger, but when running standalone, using either the debug or release versions, it also runs fine except whenever I click on any unrelated window, say a file explorer window, whereupon the app hangs without any warnings from Windows, I see the little circle thing.
The code is doing something rather computationally intensive, accessing data from a 10Mb global array, and it is well within the 2Gb limit of 32 bit Windows. I have checked for the obvious things, such as uninitialized variables, infinite loops, and the like, I am not allocating any big local arrays, but have found nothing wrong. The code is running directly from the UI thread, blocking, but I do not care as there is nothing else to do till that task completes. Alternatively, I could put this code in its own worker thread communicating back to the UI thread by an interlocked buffer, but this seems redundant. I've tried this on two different machines running Windows 7 and get identical behavior. Is there something about Windows process management that I am overlooking? Is there a way to tell whether there is some sort of memory corruption going on that could cause some other process to affect the app's process?
[Edit1 by spektre] just copied user3481340's code from comment to be readable
I do not think that the computational time, which is about an hour
has anything to do with the problem.
Rather, the windows messaging for the edit box is getting messed-up.
The relevant code is:
int textlen=GetWindowTextLength(Editwin);
int k=strcspn(messagebuf,"\n");
if(k<strlen(messagebuf))textlength=strlen(messagebuf)-k;
else textlength+=k;
SendMessage (Editwin, EM_SETSEL, (WPARAM)textlen, (LPARAM)textlen);
SendMessage (Editwin, EM_REPLACESEL, 0, (LPARAM) messagebuf);
Somehow Windows stops responding to these messages.

Answer 1

Windows7 has some changes (from previous versions of windows)
in process scheduling
which can mess up lock-less multi-thread apps which are working 100% thread safe on older versions of windows. There is not much to do with this (unless add some safety sleeps or locks)
critical sections
I am not 100% convinced that critical sections work properly on Win7SP1 as I have some issues on specific machine setup where they do not work with combination of:
heavy duty USB HS bulk data transfers
OpenGL use
multi-threading with heavy multiple critical sections use
but it could be a hidden bug or messed-up Windows7 installation or even HW error
WindowProc
if your message loop get stuck for a longer time then it should then it will cause the program to be detected as non-responding even if it is not. Usually run in compatibility for XPSP3 helps but sadly not on all machines or all apps :( this is the main reason why many games does not run on Win7
I suspect this is your case and according to your last comment I was right.
Transfer critical processing to some thread instead so the WindowProc is not blocked. If you need an event after computation is done then flag some variable as done and scan for it in some timer so you can respond inside main thread (to avoid winapi calls outside main thread).
32bit Driver+App use on x64 windows (WOW64)
if your app is accessing any driver then on WOW64 you need special driver build to access real hardware instead of emulated by WOW64 !!! If you did not then your App is most likely waiting for real device respond instead is getting emulated one which can be different and cause real hang ups. In that case you need compile your app as x64
Or use some kind of WOW64.x86 -> x64 bridge
Or use driver which can handle it itself (usually link do different dll)