For information on how your program can cause an assertion failure see the visual c

For information on how your program can cause an assertion failure see the visual c

Debug Assertion Failed!

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

‘Ares2017.exe’ (Win32): Unloaded ‘C:\Windows\SysWOW64\mfc140d.dll’
‘Ares2017.exe’ (Win32): Unloaded ‘C:\Windows\SysWOW64\combase.dll’
‘Ares2017.exe’ (Win32): Unloaded ‘C:\Windows\SysWOW64\msvcp60.dll’
Debug Assertion Failed!

Program: C:\WINDOWS\SYSTEM32\mfc140d.dll
File: d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp
Line: 196

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
‘Ares2017.exe’ (Win32): Unloaded ‘C:\Windows\SysWOW64\WinTypes.dll’
‘Ares2017.exe’ (Win32): Unloaded ‘C:\Windows\SysWOW64\WinTypes.dll’

Answers

Thanks for post here.

>>Program: C:\WINDOWS\SYSTEM32\mfc140d.dll
File: d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp
Line: 196

AFAIK, if there are more than one class inherits from CWinApp or create more than one CWinApp object in the MFC project, it will cause this issue, because each application that uses the MFC can contain only one object inherited from CWinApp.

So check your project, and make sure that you don’t have this problem first. I create a MDI project and add two object inherited from CWinApp, When I debug, it show me this:

MSDN Community Support Please remember to click «Mark as Answer» the responses that resolved your issue, and to click «Unmark as Answer» if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

>> Binary was not built with debug information.

It’s not an installation issue, the problem is, as the error message suggests, that you have not built your project with debug information.

Try this:
1) Goto Project->Properties
2) Make sure «Configuration» at the top is «Debug»
3) On the left, select «C/C++», then «General»
4) On the right, change «Debug information format» to «Program Database for edit and continue (/ZI)»
5) On the left, Select «Optimization»
6) On the right, Change «Optimization» to «Disabled (/Od)»
7) On the left, select «Code Generation»
8) On the right, change «Runtime library» to «Multi-Threaded Debug (/MTd)»
9) On the left, expand «Linker» and select «Debugging»
10) On the right, change «Generate Debug info» to » Generate Debug Information (/DEBUG) »
11) Rebuild your project.

MSDN Community Support Please remember to click «Mark as Answer» the responses that resolved your issue, and to click «Unmark as Answer» if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

All replies

Thanks for post here.

>>Program: C:\WINDOWS\SYSTEM32\mfc140d.dll
File: d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\appcore.cpp
Line: 196

AFAIK, if there are more than one class inherits from CWinApp or create more than one CWinApp object in the MFC project, it will cause this issue, because each application that uses the MFC can contain only one object inherited from CWinApp.

So check your project, and make sure that you don’t have this problem first. I create a MDI project and add two object inherited from CWinApp, When I debug, it show me this:

MSDN Community Support Please remember to click «Mark as Answer» the responses that resolved your issue, and to click «Unmark as Answer» if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

Thanks for the reply.

I search for more than one CWinApp object in the MFC project, but I don’t know how to remove them.

I attach the next triggered breakpoint.

// initialize CWinThread state
AFX_MODULE_STATE* pModuleState = _AFX_CMDTARGET_GETSTATE();
ENSURE(pModuleState);
AFX_MODULE_THREAD_STATE* pThreadState = pModuleState->m_thread;
ENSURE(pThreadState);
ASSERT(AfxGetThread() == NULL);
pThreadState->m_pCurrentWinThread = this;
ASSERT(AfxGetThread() == this);
m_hThread = ::GetCurrentThread();
m_nThreadID = ::GetCurrentThreadId();

// initialize CWinApp state
ASSERT(afxCurrentWinApp == NULL); // only one CWinApp object please
pModuleState->m_pCurrentWinApp = this;
ASSERT(AfxGetApp() == this);

// in non-running state until WinMain
m_hInstance = NULL;
m_hLangResourceDLL = NULL;
m_pszHelpFilePath = NULL;
m_pszProfileName = NULL;
m_pszRegistryKey = NULL;
m_pszExeName = NULL;
m_pszAppID = NULL;
m_pRecentFileList = NULL;
m_pDocManager = NULL;
m_atomApp = m_atomSystemTopic = NULL;
m_lpCmdLine = NULL;
m_pCmdInfo = NULL;
m_pDataRecoveryHandler = NULL;

// initialize wait cursor state
m_nWaitCursorCount = 0;
m_hcurWaitCursorRestore = NULL;

// initialize current printer state
m_hDevMode = NULL;
m_hDevNames = NULL;
m_nNumPreviewPages = 0; // not specified (defaults to 1)

// initialize DAO state
m_lpfnDaoTerm = NULL; // will be set if AfxDaoInit called

// other initialization
m_bHelpMode = FALSE;
m_eHelpType = afxWinHelp;
m_nSafetyPoolSize = 512; // default size

m_dwRestartManagerSupportFlags = 0; // don’t support Restart Manager by default
m_nAutosaveInterval = 5 * 60 * 1000; // default autosave interval is 5 minutes (only has effect if autosave flag is set)

m_bTaskbarInteractionEnabled = TRUE;

// Detect the kind of OS:
OSVERSIONINFO osvi;
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

// Fix for warnings when building against WinBlue build 9444.0.130614-1739
// warning C4996: ‘GetVersionExW’: was declared deprecated
// externalapis\windows\8.1\sdk\inc\sysinfoapi.h(442)
// Deprecated. Use VerifyVersionInfo* or IsWindows* macros from VersionHelpers.
#pragma warning( disable : 4996 )
::GetVersionEx(&osvi);
#pragma warning( default : 4996 )

// Taskbar initialization:
m_bComInitialized = FALSE;

m_pTaskbarList = NULL;
m_pTaskbarList3 = NULL;
m_bTaskBarInterfacesAvailable = TRUE;
>

For information on how your program can cause an assertion failure see the visual c

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

Debug assertion failed.

For information how your program can cause an assertion failure,see the visual c++ documentation on asserts.

(press retry to debug the application)

All replies

Debug assertion failed.

For information how your program can cause an assertion failure,see the visual c++ documentation on asserts.

(press retry to debug the application)

>i got this error while building my c++ application

Actually assertion errors occur when you’re running/debugging a program,
not when building. «Building» is the process of compiling, linking, etc.
to create the exe.

>Debug assertion failed.

Usually assert messages contain info on what condition triggered the
assertion. Is there no further info shown? Examples might ne something
like:

>building my c++ application in vs 2010
>file:f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\occcont.cpp

Also see this thread for a similar issue with VS 2005::

For information on how your program can cause an assertion failure see the visual c

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’ve created a simple logging mechanism that can write strings to a log file. Everything worked fine until I added the function fclose() to the engine class deconstructor to close the log file.

The error only occurs when fclose is called. If I comment out fclose everything runs fine. The log output is written to the file successfully either way.

Visual C++ Debug Output

Also, when commenting out the fclose call, debug output displays no errors other than a list of

Cannot find or open the PDB file.

and ends successfully with.

Answers

I think that calling this->print after fclose is the cause of the problem.

Move the call to this->print so that the file is still open when output is attempted, or use a different handle to write console output if that is what you want in the destructor.

All replies

What happens in this case: ‘if( ( this->debug == DEBUG_MODE_FILE || this->debug == DEBUG_MODE_BOTH) && this->log ) fclose(this->log)’?

I’m pretty certain at this point. Everything works perfectly if I only comment out fclose and let windows clean up on its own.

I added checks that ensure (FILE *) this->log is still okay on deconstruct, and everything works great until right at fclose, it even outputs txt to log file saying and confirming that the stream is still open for writing.

Adding breakpoint, debug values say.

Also I assumed that the Debug Output was referring to file specified here since it displays Line 17 no matter how I change the placement.

For information on how your program can cause an assertion failure see the visual c

I’m working with a Visual Studio 2015 C++ program converted from a VS 6.0 C++ program.

When I run the program it gives this error:

It’s giving this error as a user message. It is not stopping in the debugger showing a line where the error is occurring.

I used the debugger to find out where it is blowing up. It is stopping inside this for loop that is in the Carray::SetSize method found in the afxtempl.h file:

For some reason, when I first started to get this error, it was a different error message and it stopped in the debugger. I tried to get help to fix it here:

I never did figure out how to fix it, so I am hoping that someone can help in figuring out what needs to be done.

Any help that anyone can provide to resolve this error would be gratefully appreciated.

Thanks for your help.

I’m not sure of how far back to go, but in this method, a call is made to Serialize.

This is the Serialize method:

This method gets to the «try», and throws the exception. Here is what it calls in the exception processing:

This is where it tries to do SetSize and gives the error.

If I modify that method to look like this:

It does get to the «m_Filters.Add(filter);» line, but it gives this error:

This is the declaration of m_Filters

I’m not sure if a struct is a declaration, but this is what it looks like:

I’m not sure of what you mean by the rest of CMailFilter. If I do a find, there are 35 lines that have CMailFilter. Here are three methods for that name:

If I try to use the pointer method, I get four compile errors.

Should I try to adjust the code errors to use the pointer? I don’t even know what to do to fix the errors.

Here are the errors:

Here are the four code areas where the errors occur:

I have highlighted the lines containing the errors.

In void CMagicFrame::UpdateFilterLists()
CMailFilter& mf = theApp.m_Filters.ElementAt(i);
This would be CMailFilter* mf = theApp.m_Filters.ElementAt(i);

In void CExcerpt::CheckByFilters() and void DFilters::GetData()

This would be CMailFilter* mf = theApp.m_Filters.ElementAt(i);

On void DFilters::OnOK() and void DFilters::GetData() these are probably not needed.

Is there a chance that you can upload the whole project somewhere?

If this doesn’t work the last option would be to use std::vector

I have downloaded it but it doesn’t compile. openssl files are missing.

Wherever you unzip those files to, you will have to change the project «Configuration Properties\VC++ Directories\Include Directories» to point to it and the same for «Configuration Properties\VC++ Directories\Library Directories».

Yes, I did try the pointers method and I get another 13 errors. Should I try to resolve those also?

I reviewed some of the changes I made to eliminate errors when I first migrated this package from VS 6.0 to VS 2015. There were two for loops where I had to define an «i» int variable before the loops instead of in the loops. I saw where I changed the code incorrectly and changed it to the way it should be.

After that I applied your suggested changes from Jul 17, 2016 at 4:23am like this:

// m_Filters.SetSize(1);
// m_Filters.SetAt(0, filter);
m_Filters.Add(filter)

The program compiles and runs without error.

If I reverse your suggested changes, it still gives the error that I was getting after originally making the changes that you suggested.

Should I leave your suggested changes in? I don’t see any problems with the program yet, but I have not tested a parts of it.

Something in VS 2015 I just ran across that might help you migrate your project:

VS has the ability to create a new project using existing files. I used that feature to migrate a Win32 and MFC VS 6.0 projects to VS 2015.

I wouldn’t make changes as long as it works. Even small changes can lead to new problems.

I just want to make sure that what I am doing is the right thing.

After making numerous changes to fix compile errors, I was still getting the error that I posted to start this thread. You gave me this change to fix that error:

For information on how your program can cause an assertion failure see the visual c

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I’m learning c++ and I have been running into this problem when ever I try to delete dynamic memory. Here is the error that is returned when ever I am debugging a dynamic memory example.

Debug Assertion Failed!

For information on how your program can cause an assertion failure, see the visual c++ documentation on asserts.

So once this message appears I am given three options Abort, Retry, Ignore. When I chose Ignore, it brings up the file
«dbgheap.c» and points to this line of code

When I look at the varialbes that are present in the auto tab I see

‘void* _crtheap== 0x00030000’ and
‘const void *pUserData = 0x004199a0 string «2001 A Space Odyssesy»‘.

Once I’m done with this, «output.c» is brought up in the work area, and I’m seeing it is saying there are some
bad pointers, for some of «output.c» variables. Does this mean that the pointers I’m using in my code (which is
included below) are not being properly used, or is this a visual c++ problem?

HERE IS MY CODE

Any Help with this issue is greatly appreciated