Issue with Multithreading and vertical scroll bar - help needed to debug!!!

Question

I have been working on a desktop Visual Studio 2010 application for quite a few years. It is written in C++ and MFC. This code is a combination of code I have written and code I inherited. It worked great for years on Windows XP, but when I ported
it to Windows 7, a tricky problem has come up that I am having the darnest time trying to figure out
In summary, it is a single .exe desktop application. There is the main thread (thread A), which launches another thread (thread B). Both threads share a pointer to a single window object which displays events. This window also implements a vertical and horizontal
scroll bar. 
The interaction and message processing between the threads seems a little sticky to me. Both threads A and B call the same member function of the CWnd object. BUT, Thread B ALSO posts messages to thread A's queue.
So, in thread B, you will see code like this, which makes a direct call to the output window object, AND THEN it also posts a message to Thread A's mainframe window like this...
if( m_pEventLog )
pOutputWindow->AddLine("Some test...");
if( m_phNotifyWnd[RECEIVE] && m_puiEventWMsg[RECEIVE] ) {
::PostMessage( m_phNotifyWnd[RECEIVE], m_puiEventWMsg[RECEIVE], 0, (LPARAM) pPkt );
WHEN thread A receives the message that thread B posted above, it only does the following:
LRESULT CMainFrame::OnSocketReceive( WPARAM, LPARAM lParam )
CSPkt* pPkt;
CRWPkt* pRWPkt;
CSPktSocket* pSocket;
ULONG ulType;
CString csTemp;
CBSWords bsWords;
CSSSWords sssWords;
CRWPkt* pLoopBackRWMsg; // used if we have to send a loopback msg back to sender
CLMsg lmsg;
m_wndTextWindow.AddLine("Test message");
return 0;
So both threads are writing to the output window via the .AddLine() member function.
void COutputWnd::AddLine( CString& strLine, COLORREF crColor )
UpdateVScroll();
return;
And this function then makes a call to :UpdateVScroll().  The problem seems to arise because thread B does a
post to thread A, where thread A in turn writes to the output window. Eventually, the program
HANGS in the call to
SetScrollInfo() below...
void COutputWnd::UpdateVScroll()
CSingleLock lock( &m_CSVertScrollLock ); // lock things up while we are in here
BOOL bok = lock.Lock();
if (lock.IsLocked() == TRUE)
int iMax = m_FifoIndices.GetHighestIndex();
if( iMax < ( m_iMaxViewableLines - 1 ) )
iMax = 0;
//SetScrollRange( SB_VERT, 0, iMax, FALSE );
//SetScrollRange( SB_VERT, 0, 9, FALSE );
SCROLLINFO scrollinfo;
scrollinfo.cbSize = sizeof(SCROLLINFO);
scrollinfo.fMask = SIF_RANGE;
scrollinfo.nMin=0;
scrollinfo.nMax= iMax;
SetScrollInfo(SB_VERT, &scrollinfo, FALSE);
lock.Unlock();
It doesn't take long for the program to hang...maybe about 10 seconds. 
When I hit DEBUG->BREAK ALL, I get the output below in the CALL STACK WINDOW.
ntdll.dll!770070f4()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
user32.dll!76c0cde0()
user32.dll!76c018d9()
>
mfc100d.dll!AfxInternalPumpMessage()  Line 153 + 0x13 bytes
C++
mfc100d.dll!CWinThread::PumpMessage()  Line 900
C++
mfc100d.dll!CWinThread::Run()  Line 629 + 0xd bytes
C++
mfc100d.dll!_AfxThreadEntry(void * pParam=0x0022f6a4)  Line 122 + 0x13 bytes
C++
msvcr100d.dll!_callthreadstartex()  Line 314 + 0xf bytes
C
msvcr100d.dll!_threadstartex(void * ptd=0x004f97c0)  Line 297
C
kernel32.dll!762cee1c()
ntdll.dll!770237eb()
ntdll.dll!770237be()
NOTE: If I never make the call to SetScrollInfo(), the program never HANGS.
Sooo....I am trying to determine if there is a fundamental issue with the way the threads are communicating that is causing the issue, or if maybe I have a memory overwrite. It always hangs in ::SetScrollInfo(), no matter what I comment and uncomment. This
makes me think that scroll bat behavior is different in Windows 7 than on XP, but I have not been able to find any documentation about it. 
Can anyone provide any insight as to what may be the cause of the program hanging>

Answer 1

It might look like working but it will crash eventually. The windows are thread affine and other thread must never touch other threads windows. Sometimes you might get along but usually it just crashes.
Thread B must use PostMessage ( or SendMessage if suncronous action is require) to thread A's windows to achieve correct updating. Some very basic calls are implemented directly with SendMessage so they are safe to use but then you must individually check
which ones are safe.
Also having multiple SendMessage calls from B to A require rendezvous which might cause other problems ( thread B stalls or program deadlocks, depending on other program structure).
So PostMessage is the way to do it ( or create yourself another inter-thread mechanism, possible but usually too much troble)