Hi,

This question has been asked previously but the explanation was not in detail and i could never reach to the bottom of it.

I hope i can elaborate more on the problem statement and i can get a resolution/explanation from the experts here.

Consider the following two sample codes;

1.

{
	int count = 200;
	for (int i=0; i <count; ++i)
	{
		try
		{
			CDatabase *db = new CDatabase;

			BOOL bRes = db->OpenEx(_T("DSN=MyData;UID=anon;PWD=pass"));
			db->Close();

			delete db;
			db=NULL;
		}
		catch (CDBException* e)
		{
			e->Delete();
		}
	}
}

2.

{
	CDatabase *db = new CDatabase;

	int count = 200;
	for (int i=0; i <count; ++i)
	{
		try
		{
			BOOL bRes = db->OpenEx(_T("DSN=MyData;UID=anon;PWD=pass"));
			db->Close();
		}
		catch (CDBException* e)
		{
			e->Delete();
			delete db;
			db=NULL;
			return 0;
		}
	}

	delete db;
	db=NULL;
}

The first sample code leaks a lot of memory and it can be easily observed from the task manager, the memory usage keeps on growing.

The second sample code does not leak any memory if i observe the memory usage from the task manager.

To find out the cause of the memory leak i ran the code through rational purify, both the codes are leaking memory according to rational purify. The first code leaks significantly more memory than the second one. The DLL pointed by rational purify are MFC DLLs (inserting the screen shot below)

Is this a known issue with the MFC DLL or am i doing something wrong?

I have a server application where i have to create CDatabase object multiple times and i end up leaking a lot of memory over a period of time.

I can provide more information about this issue if required. Thanks in advance.

Hi

we have few C++ COM dll's which was developed around 1994 (20 years before).

Since these COM dll's places major role in our product, we are maintaining it. (And there are other reasons behind it whether to retain it or to rewrite it...)

It look so initially the COM dll source code was build using VC++6.0 and later moved to VS2005 IDE, then to VS2008 IDE...

Recently COM dll source code was build using VS2012 IDE. lot of compiler warning and few of depricated API's.

Resolved the depricated API's and analyzed the warnings.

After successful compilation, when we used for stress testing the app get crashed in the load environment and fixed them.

and now we have VS2013 IDE,

Keep all these, looking for some suggestion on how to avoid reworking and release a bug free product.

BR

mvcpp

Hi All,

I was do the products migrating from desktop to surface and other tablets that support Windows OS. 

Our product was implemented MFC & ATL, the main product worked as container, then the sub process was launched.

        When try to close the sub-process, it will popup a modal-dialog. If the modal-dialog was issued via surface pen, the application will hang. It works fine if click by hand from touch screen or by mouse clicking.

The main process's UI thread:

0:000> !wow64exts.sw
Switched to 32bit mode
0:000:x86> kv fff
  Memory  ChildEBP RetAddr  Args to Child
          0018dd60 76d30927 00000002 0018df0c 00000001 ntdll_77b40000!ZwWaitForMultipleObjects+0xc (FPO: [5,0,0])
      184 0018dee4 776bb6e5 0018debc 0018df0c 00000000 KERNELBASE!WaitForMultipleObjectsEx+0xcc (FPO: [SEH])
       58 0018df3c 7796c1db 00000000 0018df94 000003e8 user32!MsgWaitForMultipleObjectsEx+0x159 (FPO: [Non-Fpo])
       34 0018df70 77a33271 0018df94 00000001 0018df9c combase!CCliModalLoop::BlockFn+0x101 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\blue_gdr\com\combase\dcomrem\callctrl.cxx @ 1571]
       6c 0018dfdc 77a316cd 0018e27c 0ec9f2e4 090dc4b0 combase!ThreadSendReceive+0x1d3 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\channelb.cxx @ 5776]
      148 0018e124 7796c6ac 0ec9f2e4 0018e27c 0018e264 combase!CRpcChannelBuffer::SendReceive2+0x1df (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\channelb.cxx @ 4796]
       c0 0018e1e4 77933b8f 0ec9f2e4 0018e27c 0018e264 combase!ClassicSTAThreadSendReceive+0x209 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\callctrl.cxx @ 696]
       5c 0018e240 77a314a5 0ec9f2e4 0018e27c 0018e264 combase!CCtxComChnl::SendReceive+0xf9 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\ctxchnl.cxx @ 790]
       18 0018e258 75995ee5 0eb32fbc 0018e2a8 75a0e9d0 combase!NdrExtpProxySendReceive+0x42 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\ndr\ndrole\proxy.cxx @ 2017]
        c 0018e264 75a0e9d0 379b6970 0018ea38 0018ea14 rpcrt4!NdrpProxySendReceive+0xe (FPO: [0,0,0])
      440 0018e6a4 75aa1a9c 75a798c0 75a7e87a 0018e6c4 rpcrt4!NdrClientCall2+0x2d6 (FPO: [SEH])
       18 0018e6bc 75aa1a4d 0eb32fbc ffffff91 74eb5f88 oleaut32!IDispatch_RemoteInvoke_Proxy+0x24 (FPO: [12,1,0])
      2dc 0018e998 74f711d6 0eb32fbc ffffff91 74eb5f88 oleaut32!IDispatch_Invoke_Proxy+0xf1 (FPO: [Non-Fpo])
       d0 0018ea68 74f71527 ffffff91 00000001 0000000b mfc90u!COleDispatchDriver::InvokeHelperV+0x324
       20 0018ea88 00411f6a 0f1dfff8 ffffff91 00000001 mfc90u!COleDispatchDriver::InvokeHelper+0x20
       9c 0018eb24 0042669d 0f1dff28 0018eb8c 004226b4 VStudio!AOADispDriver::Close+0xea (FPO: [Non-Fpo]) (CONV: thiscall)
        c 0018eb30 004226b4 427fc568 00020462 0018eb24 VStudio!PrjCntrItem::CloseComponent+0x2d (FPO: [Non-Fpo]) (CONV: thiscall)
       5c 0018eb8c 74f3dcbf 0396c360 00000000 0018ebb4 VStudio!PrjContainerDoc::SaveModified+0x104 (FPO: [Non-Fpo]) (CONV: thiscall)
       10 0018eb9c 74f15180 0f7b7420 74f1514e 00000000 mfc90u!CDocument::CanCloseFrame+0x41
       18 0018ebb4 74f0fb03 3700a788 00000010 0f7b7420 mfc90u!CFrameWnd::OnClose+0x32
       a4 0018ec58 74f0f6cc 00000010 00000000 00000000 mfc90u!CWnd::OnWndMsg+0x410
       20 0018ec78 74f0e2f2 00000010 00000000 00000000 mfc90u!CWnd::WindowProc+0x24
       68 0018ece0 74f0e57e 00000000 00050520 00000010 mfc90u!AfxCallWndProc+0xa3
       24 0018ed04 74f0c234 00050520 00000010 00000000 mfc90u!AfxWndProc+0x37
       48 0018ed4c 776b791c 00050520 00000010 00000000 mfc90u!AfxWndProcBase+0x56
       2c 0018ed78 776b7b7a 74f0c1de 00050520 00000010 user32!_InternalCallWinProc+0x23
       90 0018ee08 776bc7be 74f0c1de 00000000 00000010 user32!UserCallWinProcCheckWow+0x184 (FPO: [SEH])
       38 0018ee40 778ae02c 74f0c1de 00050520 00000010 user32!CallWindowProcW+0x83 (FPO: [Non-Fpo])
       50 0018ee90 778ae4b0 00000010 00000000 00000000 ole32!CFrameFilter::OnMessage+0x88 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\blue_gdr\com\ole32\ole232\inplace\inplace.cpp @ 2146]
       1c 0018eeac 776b791c 00050520 00000010 00000000 ole32!FrameWndFilterProc+0x6a (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\ole32\ole232\inplace\inplace.cpp @ 1159]
       2c 0018eed8 776b7b7a 778ae446 00050520 00000010 user32!_InternalCallWinProc+0x23
       90 0018ef68 776b7ccd 778ae446 00000000 00000010 user32!UserCallWinProcCheckWow+0x184 (FPO: [SEH])
       60 0018efc8 776b7e23 009606b0 00000000 00000010 user32!DispatchClientMessage+0xdc (FPO: [Non-Fpo])
       38 0018f000 77b7c692 0018f018 00000000 0018f260 user32!__fnDWORD+0x36 (FPO: [1,6,0])
       34 0018f034 776bad43 00050520 00000112 0000f060 ntdll_77b40000!KiUserCallbackDispatcher+0x2e (FPO: [0,0,0])
       90 0018f0c4 776ba0ab 009606b0 00000000 009b0337 user32!RealDefWindowProcWorker+0x13f (FPO: [Non-Fpo])
       18 0018f0dc 74881814 00050520 00000112 0000f060 user32!RealDefWindowProcW+0x53 (FPO: [Non-Fpo])
       14 0018f0f0 748aac55 01ce2db8 0018f210 748817aa uxtheme!DoMsgDefault+0x21 (FPO: [0,0,0])
        c 0018f0fc 748817aa 01ce2db8 0018f1a4 7772e280 uxtheme!OnDwpSysCommand+0x2a (FPO: [Non-Fpo])
      114 0018f210 74881ddf 0000f060 009b0337 00000001 uxtheme!_ThemeDefWindowProc+0x755 (FPO: [Non-Fpo])
       14 0018f224 776ba042 00050520 00000112 0000f060 uxtheme!ThemeDefWindowProcW+0x18 (FPO: [4,0,0])
       4c 0018f270 776e3bbb 00050520 00000112 0000f060 user32!DefWindowProcW+0x158 (FPO: [SEH])
       3c 0018f2ac 776d5782 0000f060 009b0337 00000000 user32!DefMDIChildProcWorker+0xe79a
       14 0018f2c0 74f18c87 00050520 00000112 0000f060 user32!DefMDIChildProcW+0x18 (FPO: [4,0,0])
       18 0018f2d8 4c0e215a 00000112 0000f060 009b0337 mfc90u!CMDIChildWnd::DefWindowProcW+0x17
       2c 0018f304 74f0e3c1 00000000 0000f060 009b0337 ot1101asu!SECMDIChildWnd::DefWindowProcW+0x12a (FPO: [3,3,0]) (CONV: thiscall) [c:\program files\rogue wave\stingray studio 10.1\src\toolkit\mdi\swinmdi.cpp @ 4177]
       14 0018f318 74f15604 0f7b7420 00432250 0018f33c mfc90u!CWnd::Default+0x30 (FPO: [0,0,1])
       10 0018f328 00432267 0000f060 009b0337 0f7b7420 mfc90u!CFrameWnd::OnSysCommand+0x50
       14 0018f33c 74f0fd15 0000f060 009b0337 3700bf18 VStudio!PrjMDIChild::OnSysCommand+0x17 (FPO: [Non-Fpo]) (CONV: thiscall)
       ac 0018f3e8 74f0f6cc 00000112 0000f060 009b0337 mfc90u!CWnd::OnWndMsg+0x622
       20 0018f408 74f0e2f2 00000112 0000f060 009b0337 mfc90u!CWnd::WindowProc+0x24
       68 0018f470 74f0e57e 00000000 00050520 00000112 mfc90u!AfxCallWndProc+0xa3
       24 0018f494 74f0c234 00050520 00000112 0000f060 mfc90u!AfxWndProc+0x37
       44 0018f4d8 776b791c 00050520 00000112 0000f060 mfc90u!AfxWndProcBase+0x56
       2c 0018f504 776b7b7a 74f0c1de 00050520 00000112 user32!_InternalCallWinProc+0x23
       90 0018f594 776bc7be 74f0c1de 00000000 00000112 user32!UserCallWinProcCheckWow+0x184 (FPO: [SEH])
       38 0018f5cc 778ae31d 74f0c1de 00050520 00000112 user32!CallWindowProcW+0x83 (FPO: [Non-Fpo])
       28 0018f5f4 778ae4a6 0000f060 009b0337 009b0337 ole32!CFrameFilter::OnSysCommand+0x54 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\blue_gdr\com\ole32\ole232\inplace\inplace.cpp @ 1577]
       18 0018f60c 776b791c 00050520 00000112 0000f060 ole32!FrameWndFilterProc+0x60 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\ole32\ole232\inplace\inplace.cpp @ 1154]
       2c 0018f638 776b925d 778ae446 00050520 00000112 user32!_InternalCallWinProc+0x23
       90 0018f6c8 776b7ccd 778ae446 00000000 00000112 user32!UserCallWinProcCheckWow+0x23c (FPO: [SEH])
       60 0018f728 776b7e23 009606b0 00000000 00000112 user32!DispatchClientMessage+0xdc (FPO: [Non-Fpo])
       38 0018f760 77b7c692 0018f778 00000000 0018f9c0 user32!__fnDWORD+0x36 (FPO: [1,6,0])
       34 0018f794 776bca50 00050520 00000112 0000f060 ntdll_77b40000!KiUserCallbackDispatcher+0x2e (FPO: [0,0,0])
       6c 0018f800 776bcb8c 009606b0 00000000 009b0337 user32!SendMessageWorker+0x2bd (FPO: [Non-Fpo])
       34 0018f834 7490f81e 00050520 00000112 0000f060 user32!SendMessageW+0x12e (FPO: [Non-Fpo])
       28 0018f85c 748817aa 01ce2db8 0018f904 7772e280 uxtheme!OnDwpNcLButtonDown+0x56459
      114 0018f970 74881ddf 00000014 009b0337 00000001 uxtheme!_ThemeDefWindowProc+0x755 (FPO: [Non-Fpo])
       14 0018f984 776ba042 00050520 000000a1 00000014 uxtheme!ThemeDefWindowProcW+0x18 (FPO: [4,0,0])
       4c 0018f9d0 776e3bbb 00050520 000000a1 00000014 user32!DefWindowProcW+0x158 (FPO: [SEH])
       38 0018fa08 776d5782 00000014 009b0337 00000000 user32!DefMDIChildProcWorker+0xe79a
       14 0018fa1c 74f18c87 00050520 000000a1 00000014 user32!DefMDIChildProcW+0x18 (FPO: [4,0,0])
       18 0018fa34 4c0e215a 000000a1 00000014 009b0337 mfc90u!CMDIChildWnd::DefWindowProcW+0x17
       2c 0018fa60 74f0e3c1 00000000 00000014 009b0337 ot1101asu!SECMDIChildWnd::DefWindowProcW+0x12a (FPO: [3,3,0]) (CONV: thiscall) [c:\program files\rogue wave\stingray studio 10.1\src\toolkit\mdi\swinmdi.cpp @ 4177]
       14 0018fa74 4c0e1ac4 0f7b7420 4c0e1a90 74f0fb36 mfc90u!CWnd::Default+0x30 (FPO: [0,0,1])
        c 0018fa80 74f0fb36 00000014 00000337 0000009b ot1101asu!SECMDIChildWnd::OnNcLButtonDown+0x34 (FPO: [3,0,0]) (CONV: thiscall) [c:\program files\rogue wave\stingray studio 10.1\src\toolkit\mdi\swinmdi.cpp @ 3785]
       b0 0018fb30 74f0f6cc 000000a1 00000014 009b0337 mfc90u!CWnd::OnWndMsg+0x443
       20 0018fb50 74f0e2f2 000000a1 00000014 009b0337 mfc90u!CWnd::WindowProc+0x24
       68 0018fbb8 74f0e57e 00000000 00050520 000000a1 mfc90u!AfxCallWndProc+0xa3
       24 0018fbdc 74f0c234 00050520 000000a1 00000014 mfc90u!AfxWndProc+0x37
       44 0018fc20 776b791c 00050520 000000a1 00000014 mfc90u!AfxWndProcBase+0x56
       2c 0018fc4c 776b7b7a 74f0c1de 00050520 000000a1 user32!_InternalCallWinProc+0x23
       90 0018fcdc 776bc7be 74f0c1de 00000000 000000a1 user32!UserCallWinProcCheckWow+0x184 (FPO: [SEH])
       38 0018fd14 778ae02c 74f0c1de 00050520 000000a1 user32!CallWindowProcW+0x83 (FPO: [Non-Fpo])
       50 0018fd64 778ae4b0 000000a1 00000014 009b0337 ole32!CFrameFilter::OnMessage+0x88 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\blue_gdr\com\ole32\ole232\inplace\inplace.cpp @ 2146]
       1c 0018fd80 776b791c 00050520 000000a1 00000014 ole32!FrameWndFilterProc+0x6a (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\ole32\ole232\inplace\inplace.cpp @ 1159]
       2c 0018fdac 776b7b7a 778ae446 00050520 000000a1 user32!_InternalCallWinProc+0x23
       90 0018fe3c 776b97f4 778ae446 00000000 000000a1 user32!UserCallWinProcCheckWow+0x184 (FPO: [SEH])
       6c 0018fea8 776b9859 ffffffa1 0018fee4 74f4e491 user32!DispatchMessageWorker+0x208 (FPO: [Non-Fpo])
        c 0018feb4 74f4e491 00662f00 00000000 0045bb10 user32!DispatchMessageW+0x10 (FPO: [1,1,0])
       10 0018fec4 74f4eb18 0045bb10 0045bb10 ffffffff mfc90u!AfxInternalPumpMessage+0x40 (FPO: [0,0,2])
       20 0018fee4 74f1af81 0045c120 00000001 00000000 mfc90u!CWinThread::Run+0x5b
       14 0018fef8 004399cf 00400000 00000000 0065185e mfc90u!AfxWinMain+0x6a
       94 0018ff8c 7579919f 7ffde000 0018ffdc 77b90bbb VStudio!__tmainCRTStartup+0x150 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578]
        c 0018ff98 77b90bbb 7ffde000 35f99669 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
       44 0018ffdc 77b90b91 ffffffff 77b7c9d3 00000000 ntdll_77b40000!__RtlUserThreadStart+0x20 (FPO: [SEH])
       10 0018ffec 00000000 00439b3e 7ffde000 00000000 ntdll_77b40000!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

And the sub-process's thread:

0:000> !wow64exts.sw
Switched to 32bit mode
0:000:x86> kv fff
  Memory  ChildEBP RetAddr  Args to Child
          0018ece0 7581dc23 00000001 000301ca 00000000 user32!NtUserWaitMessage+0xc (FPO: [0,0,0])
       40 0018ed20 75810407 00000001 00000000 00000000 user32!DialogBox2+0x13f (FPO: [Non-Fpo])
       30 0018ed50 75860ae4 000301ca 7581caef 0018ef98 user32!InternalDialogBox+0x107 (FPO: [Non-Fpo])
       c4 0018ee14 7585fa16 0018ef98 025976f8 000301ca user32!SoftModalMessageBox+0xdd7 (FPO: [1,39,4])
      16c 0018ef80 7585f75d 00000004 025976f8 00000000 user32!MessageBoxWorker+0x27f (FPO: [0,85,4])
       80 0018f000 7585f542 000301ca 025976f8 01ccec88 user32!MessageBoxTimeoutW+0x6b (FPO: [6,27,4])
       20 0018f020 7585f78e 000301ca 025976f8 01ccec88 user32!MessageBoxExW+0x1b (FPO: [5,0,0])
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for VSSupport.dll -
       1c 0018f03c 671191c2 000301ca 025976f8 01ccec88 user32!MessageBoxW+0x18 (FPO: [4,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
       44 0018f080 74fe0a65 025976f8 00000023 00000073 VSSupport!ZWinApp::DoMessageBox+0x102
       34 0018f0b4 00403520 00000073 00000003 ffffffff mfc90u!AfxMessageBox+0x40
       1c 0018f0d0 671171b7 02582460 0018f17c 75012927 AlmCfgEd!CAlmCfgEdDoc::OnCloseRequest+0x60 (FPO: [Non-Fpo]) (CONV: thiscall)
        c 0018f0dc 75012927 74fffd23 751551aa 8bfb7d36 VSSupport!ZSptOleServerDoc::CloseRequest+0x17
       a0 0018f17c 750003f0 67120580 00000001 0018f6b0 mfc90u!_AfxDispatchCall+0x10
       a4 0018f220 765018a2 00000001 ffffff91 05952324 mfc90u!COleDispatchImpl::Invoke+0x388
       40 0018f260 764e0b2b 05952324 00000000 00000001 oleaut32!IDispatch_Invoke_Stub+0x66 (FPO: [10,2,4])
       34 0018f294 7604e0b9 0018f2d0 fde82820 764e0aa0 oleaut32!IDispatch_RemoteInvoke_Thunk+0x5b (FPO: [1,1,0])
      684 0018f918 763504d5 00214a28 00205d58 0024cad4 rpcrt4!NdrStubCall2+0x847 (FPO: [SEH])
       48 0018f960 764ed857 00214a28 0024cad4 00205d58 combase!CStdStubBuffer_Invoke+0x96 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\ndr\ndrole\stub.cxx @ 1590]
       24 0018f984 7635039d 00201ec8 0024cad4 00205d58 oleaut32!CStubWrapper::Invoke+0x47 (FPO: [Non-Fpo])
       8c 0018fa10 76253733 0022c680 74f558e0 00205d58 combase!SyncStubInvoke+0x144 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\channelb.cxx @ 1664]
      12c 0018fb3c 76351198 00205d58 0024cad4 00201ec8 combase!CCtxComChnl::ContextInvoke+0x222 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\ctxchnl.cxx @ 1377]
       a8 0018fbe4 76350bc2 00201ec8 02582470 05952320 combase!AppInvoke+0x258 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\channelb.cxx @ 1469]
      15c 0018fd40 7625277e 0024ca78 762524dd 0000babe combase!ComInvokeWithLockAndIPID+0x5fb (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\channelb.cxx @ 2311]
       34 0018fd74 757f791c 0001055c 00000400 0000babe combase!ThreadWndProc+0x2ad (FPO: [Non-Fpo]) (CONV: stdcall) [d:\blue_gdr\com\combase\dcomrem\chancont.cxx @ 683]
       2c 0018fda0 757f7b7a 762524dd 0001055c 00000400 user32!_InternalCallWinProc+0x23
       90 0018fe30 757f97f4 762524dd 00000000 00000400 user32!UserCallWinProcCheckWow+0x184 (FPO: [SEH])
       6c 0018fe9c 757f9859 00000400 0018fed8 74fde491 user32!DispatchMessageWorker+0x208 (FPO: [Non-Fpo])
        c 0018fea8 74fde491 001ec888 00000000 0042f590 user32!DispatchMessageW+0x10 (FPO: [1,1,0])
       10 0018feb8 74fdeb18 0042f590 0042f590 ffffffff mfc90u!AfxInternalPumpMessage+0x40 (FPO: [0,0,2])
       20 0018fed8 671190bc 0042f590 0018fef8 74faaf81 mfc90u!CWinThread::Run+0x5b
        c 0018fee4 74faaf81 00431e88 00000001 00000000 VSSupport!ZWinApp::Run+0x2c
       14 0018fef8 0041c62f 00400000 00000000 001d18e4 mfc90u!AfxWinMain+0x6a
       94 0018ff8c 763a919f 7ffde000 0018ffdc 77c30bbb AlmCfgEd!__tmainCRTStartup+0x150 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 578]
        c 0018ff98 77c30bbb 7ffde000 fc261a3b 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [1,0,0])
       44 0018ffdc 77c30b91 ffffffff 77c1c9c8 00000000 ntdll_77be0000!__RtlUserThreadStart+0x20 (FPO: [SEH])
       10 0018ffec 00000000 0041c79e 7ffde000 00000000 ntdll_77be0000!_RtlUserThreadStart+0x1b (FPO: [2,2,0])

Please help.

If this topic was not suitable being discussed here, please help advise.

Thanks,

Levi

One world, one dream

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 apost to thread A, where thread A in turn writes to the output window. Eventually, the programHANGS 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 bytesC++
mfc100d.dll!CWinThread::PumpMessage()  Line 900C++
mfc100d.dll!CWinThread::Run()  Line 629 + 0xd bytesC++
mfc100d.dll!_AfxThreadEntry(void * pParam=0x0022f6a4)  Line 122 + 0x13 bytesC++
msvcr100d.dll!_callthreadstartex()  Line 314 + 0xf bytesC
msvcr100d.dll!_threadstartex(void * ptd=0x004f97c0)  Line 297C
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>

Which redistributable package should be installed at the client side for binaries built with either Visual C++ 2013 Update 3 or 4? 

From the Download Center, "Visual C++ Redistributable Packages for Visual Studio 2013",http://www.microsoft.com/en-us/download/details.aspx?id=40784 I downloaded "vcredist_x86.exe" and "vcredist_x64.exe", which have version number 12.0.21005.1

My system, which has installed VS2013 Update 3, also has "vcredist_x86.exe" and "vcredist_x64.exe", at "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\1033", but these having a higher version number: 12.0.30501.0

A colleague of mine has installed  VS2013 Update 4, but has the same redistributable files as my VS2013 Update 3 installation: version 12.0.30501.0.

Is it correct to conclude that

1. the VS2013 redistributables at Microsoft's Download Center (12.0.21005.1) are outdated?
2. VS2013 Update 3 and Update 4 based applications may share the very same redistributable package (12.0.30501.0)?

I am looking at a WinDbg dump whose analysis contains the following:

FAULTING_MODULE: 76dd0000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP:  4d8cef27

ERROR_CODE: (NTSTATUS) 0xc0000264 - {Application Error}  The application attempted to release a resource it did not own. Click OK to terminate the application.

EXCEPTION_CODE: (NTSTATUS) 0xc0000264 - {Application Error}  The application attempted to release a resource it did not own. Click OK to terminate the application.

Thisexceptionoccurs after a the following code is called from our application. This code can run on weeks on end and then BANG... I get a dump with the above error.

I know it seems weird but there really is not any code between these two Critical Section statements.  This code is used as a embedded "safety" check to ensure that no other thread is reading and it is safe move to do other write logic work below which is protected by its own Critical Section. 

{           EnterCriticalSection(&m_csReadLock);

// if we made it here, there is no read in progress

LeaveCriticalSection(&m_csReadLock);
}

What is confusing me is the thread that dumps is the OwningThread for the critical section.  Meaning the other threads (11), which are  waiting to write, show the Critical Section for the read lock with an OwningThread of Zero.  It appears that LeaveCriticalSection at least partially completes and the OwningThread for m_csReadLock structure seems to have been zeroed out.  And it is zero everywhere.  Running a test case that doesn't fail, shows that is the expected behavior.

We are running Windows Server 2008 Standard SP2, 2.9GHz, Quad CPU (2 proc), 4 Gig Mem, 32 bit OS.  This code was originally built with VS6.0 and has been ported to VS2005.

How can this occur other than memory corruption of some type? 

Is there any know bug in this area? I can’t seem to find much online regarding this particular error.

Is there anything intrinsically wrong with doing the Enter/Leave critical section one after the other?

I obviously suspect a threading issue.  It just does not seem to be the case due to theconsistencyof the dump.

Any help is appreciated.

Hi,

I'm trying to change MFC ribbon image on ribbon, but it doesn't work when I set to different image index.

Anyone knows why?

Thanks

Daniel

Hi,

I am having an propertysheet based application which is of size (640 X 480) pixels.When I am trying to run it on a Japanese windows 7 operating system then the size is getting increased to (750 X 470) pixels.

I did a sample dialog based application of border style "Dialog Frame" now interesting thing what I found is this dialog based application is not resized.

Can anyone please let me know how can I prevent the propertysheet from getting resized.

Thanks in advance.

SivaV

Hello,

I'm a C++ developer using VS 2012 and VS 2010 for developing AAA titles. I have read about not using STL and other stuff provided in the standard headers that come with VS. I read most of the stuff on the websites based on game programming and some are really from the people well known in the industry. I have seen cases where they wont even use vector, list, map and others and not even use utility functions and algorithms. In such cases they write those containers and stuff themselves which has almost the same interface and so much of debug and implementation time spent on such huge code.

I have two questions:

1: Isn't the C++ implementation that comes with VS optimized for the platform for better performance? Isn't it using some intrinsic functions that people on the client end doesn't know about and supplying their own implementation would indeed be more slower in basic container operations such as insert, remove, find, swap, copy? Lets assume that we supply our own custom allocators for faster memory management to every container that we use. Also, they take care of fragmentation, alignment and stuff. Why develop custom containers with almost same interface, why not spend that time on writing allocators and other stuff that might actually help?

2: There are times when we include a lot, a lot, of unnecessary stuff through the standard headers in a huge code base. Unnecessary, because we only needed a thing or two from such huge headers including other huge headers and so on. Now, I know templates aren't instantiated unless used, same goes for the members functions inside them and blah blah. Since, these are precompiled headers, it is safe to assume that there is no compile time hit for that unnecessary stuff. My question is, is there any hidden effect of such inclusions on code size (executable) that grows with the huge growth of the code base? In my opinion there shouldn't be, but I wanna know I'm not mistaken just in case. 

Hi,

Have converted a working vs2013 project to vs2015 preview and then CTP, I get a parser error when the WinForm designer tries to redraw the form. The converted code runs and compiles fine both in debug and release modes, and it seems the CodeDOM is not able to see the classes defined in one of the referenced assemblies, which in fact isolates the problem to the way the form designer tries to pull in these referenced assemblies. My impression was that the code has to be built using the /clrpure in particular or /clrsafe, and the latter was the switch used for the project since vs2005. There are inquiries on the forum expressing the designer misbehavior if the switches are not accordingly used for the C++ projects. 

Now building the code with the same switch in vs2015 gives the warning that /clrpure is deprecated, and altering it to /clr or /clrsafe although all generate a running code with the winform behaving properly, does not resolve the WinForm designer error.

It is nice to know if there is a workaround for this, or a way to step within the designer code to find out exactly what the cause of error could be, using the debugger. The call stack only shows the calls within the visual studio assemblies, and testing hypothetical workarounds for a large size project is not that feasible either.

Best Regards,

AliReza Bemanian, Ph.D.

Hi,

Here is my problem:

I have a VC++ MFC dialog based application. There I am adding a Button to my dialog by just drag and drop from the tool box.

I am also having a MyCustomButton.dll to give new looks to the button.

Inside MyCustomButton.dll, MyCustomButton.cpp is the button class which is derived from CButton. 

Now I want the behavior of my application in such a way at execution of my application, like if the  MyCustomButton.dll is present in system then the button of my dialog should look like as per implementation of MyCustomButton.dll, where as if the dll is not present normal MFC button should get displayed.

Please guide me in achieving this. How can I make my application (*.exe) decide at run time.

Thanks in Advance,

Thanks & Regards, Mayank Agarwal

As the title says, the Visual C++ 2010 compiler is not suppressing warning C4200 as directed. It's working correctly with other warnings however.

I've tried including the "C" prefix in both the command line and via #pragma and also tried reordering the list of suppressed warning IDs in both methods but to no avail.

This worked fine in VS2008.

-Matt

Hi,

I'm using  CMFCRibbonPanel. When I had removed CMFCRibbonButton on position 0 on panel position 0 category position 1 on panel I got bug Unhandled exception at 0x0F95545F (mfc120d.dll) in my.exe: 0xC0000005: Access violation reading location 0xFEEEFEEE when I call AdjustSizeImmediate().

Button removing  works good on other position.

My code:

(CMFCRibbonButton*)m_wndRibbonBar.GetCategory(1)->GetPanel(0)->Remove(5);
(CMFCRibbonButton*)m_wndRibbonBar.GetCategory(1)->GetPanel(0)->Remove(4);
(CMFCRibbonButton*)m_wndRibbonBar.GetCategory(1)->GetPanel(0)->Remove(3);
(CMFCRibbonButton*)m_wndRibbonBar.GetCategory(1)->GetPanel(0)->Remove(2);
(CMFCRibbonButton*)m_wndRibbonBar.GetCategory(1)->GetPanel(0)->Remove(1);
m_wndRibbonBar.AdjustSizeImmediate(); // OK
(CMFCRibbonButton*)m_wndRibbonBar.GetCategory(1)->GetPanel(0)->Remove(0);
m_wndRibbonBar.AdjustSizeImmediate(); // bug

I got same error when I used:

m_wndRibbonBar.GetCategory(1)->RemovePanel(0);
m_wndRibbonBar.AdjustSizeImmediate(); // bug

Can you help me?

Thanx Tom

Hello,

I'm trying to a old project (VC6++) on Visual Studio 2013.But it gives me an error i don't know how to solve.I've searched google but can't find any solutions.

Here is an error:

Error1error C1001: An internal error has occurred in the compiler.C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\mutex461Shared

Compiler Output

1>------ Build started: Project: Shared, Configuration: Release Win32 ------
1>  stdafx.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\mutex(46): fatal error C1001: An internal error has occurred in the compiler.
1>  (compiler file 'msc1.cpp', line 1325)
1>   To work around this problem, try simplifying or changing the program near the locations listed above.
1>  Please choose the Technical Support command on the Visual C++
1>   Help menu, or open the Technical Support help file for more information
1>  INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe'
1>      Please choose the Technical Support command on the Visual C++
1>      Help menu, or open the Technical Support help file for more information
2>------ Build started: Project: AIServer, Configuration: Release Win32 ------
2>  StdAfx.cpp
2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\mutex(46): fatal error C1001: An internal error has occurred in the compiler.
2>  (compiler file 'msc1.cpp', line 1325)
2>   To work around this problem, try simplifying or changing the program near the locations listed above.
2>  Please choose the Technical Support command on the Visual C++
2>   Help menu, or open the Technical Support help file for more information
2>  INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe'
2>      Please choose the Technical Support command on the Visual C++
2>      Help menu, or open the Technical Support help file for more information
========== Build: 0 succeeded, 2 failed, 0 up-to-date, 0 skipped ==========

I've tried on Visual Studio 2012 successfull but on Visual Studio 2013 gives me that error.

How can i solve this ?

Thanks...

[Sorry About English]

mbpakalin.net

Hello, I've just intalled visual studio 2010 and faced the issue with C++ projects: when I create a new console application or win32 project I see the message:

"An error occurred while creating or opening C++ browsing database file z:\test\test.sdf. IntelliSense and browsing information will not be available for C++ projects.

Ensure that Microsoft SQL Server Compact 3.5 is installed and that no other applications are accessing the file. If this problem persists, delete the file and reopen the solution".

In the list of programs I see SQL Server Compact 3.5 SP2 ENU and SQL Server Compact 3.5 x64 ENU installed:

 And .sdf file doesn't exist so it is nothing to delete or share with another application. I've already tried to repair Visual Studio via control panel, but the problem still persists.

I'm using Windows 7 Ultimate x64 build 7600 and visual studio 2010 ultimate x86.

The following code does not give me the desired result even after using InterlockedIncrement function. What is wrong?

#include <iostream>
using namespace std;
#include <Windows.h>

long g_x = 1;

DWORD WINAPI  Incr(void* p )
{
	//::InterlockedIncrement(&g_x);
	InterlockedExchangeAdd(&g_x,1);
	return 0;
}
#define MAX 100
int main()
{
	HANDLE hThreads[MAX];
	DWORD dwTD;

	int iCtr = 0;
	for( ; iCtr < MAX; iCtr++ )
	{
		hThreads[iCtr] = ::CreateThread(NULL,0,Incr,NULL,0,&dwTD);
	}
	::WaitForMultipleObjects( MAX , hThreads, TRUE, INFINITE );

	cout<<"g_x = "<<g_x<<endl;

	return 0;
}

I've been using VS2010 Pro to work on Widows Forms projects.
Now I've been asked to update an old VC++ MFC app that was written 10 years ago by someone who doesn't work here anymore.

I found the old project files, but I can't get Visual Studio to open or convert them.  How do I install the libraries, compiler, etc., that I need?

Thanks!