求助！电脑不断弹出debug assertion failed，关机之后就启动不了了?
&img src=&/a172f780ee0_b.jpg& data-rawheight=&800& data-rawwidth=&1080& class=&origin_image zh-lightbox-thumb& width=&1080& data-original=&/a172f780ee0_r.jpg&&&br&再开机就一直卡在下图这里&img src=&/3617afabe79a5adb8a93ec99a11774af_b.jpg& data-rawheight=&800& data-rawwidth=&1080& class=&origin_image zh-lightbox-thumb& width=&1080& data-original=&/3617afabe79a5adb8a93ec99a11774af_r.jpg&& 大家能不能帮我看看问题出在哪了，我自己没法解决，谢谢！
再开机就一直卡在下图这里…这个报错（debug assertion failed）是什么意思？
[问题点数：20分，结帖人caplisimi]
这个报错（debug assertion failed）是什么意思？
[问题点数：20分，结帖人caplisimi]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
本帖子已过去太久远了，不再提供回复功能。艾尔之光无法打开客户端_百度知道
艾尔之光无法打开客户端
点现客户端再双击打显示运行确定跳 Debug Assertion Failed 没办打
删掉官网载用普通载问题昂
其他类似问题
为您推荐：
艾尔之光的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁VC知识库:请教高手，这个错误提示是什么意思?
主&&&&&&题: 请教高手，这个错误提示是什么意思?
作&&&&&&者: Megan
回复次数: 8
正文内容: 运行时，我点击一按钮(启用多线程)，出现错误，弹出一对话框，
标题是：Microsoft Virsual C++ Debug Library
上面内容为：
&&&&&&&&&& Debug Assertion Failed!
&&&&&&&&&& Program: F:\test.exe
&&&&&&&&&& File: wincore.cpp
&&&&&&&&&& Line: 980
&&&&&&&&&& For information on how your program can cause an assertion failure,
&&&&&&&&&& see the virsual C++ documentation on asserts.
我找到文件wincore.cpp的Line:980，为
&&&&&&&&&&&& ASSERT(pMap-&LookupPermanent(hWndOrig) == NULL);
请教高手，这句话是什么意思呢，使出现了什么错误？
test.exe是程序生成的可执行文件
回复人: YangTze (得分：1) 8:52:50
你的创建代码及其线程代码？
回复人: hengai (得分：1) 8:53:10
pMap-&LookupPermanent(hWndOrig) != NULL，所以会触发 ASSERT
回复人: 困惑者 (得分：1) 8:53:34
断言失败了，debug一下
回复人: YangTze (得分：5) 8:54:05
细细阅读！Knowledge Base&&
CWnd Derived MFC Objects and Multi-threaded Applications
PSS ID Number: Q147578
Article Last Modified on 07-30-2001
--------------------------------------------------------------------------------
The information in this article applies to:
The Microsoft Foundation Classes (MFC)
Microsoft Visual C++, 32-bit Editions 2.0, 2.1, 2.2, 4.0, 4.1
Microsoft Visual C++, 32-bit Enterprise Edition 4.2
Microsoft Visual C++, 32-bit Professional Edition 4.2
Microsoft Visual C++, 32-bit Enterprise Edition 5.0
Microsoft Visual C++, 32-bit Professional Edition 5.0
Microsoft Visual C++, 32-bit Enterprise Edition 6.0
Microsoft Visual C++, 32-bit Professional Edition 6.0
Microsoft Visual C++, 32-bit Learning Edition 6.0
--------------------------------------------------------------------------------
In a multi-threaded application written using MFC, you should not pass MFC objects across thread boundaries. As a general rule, a thread should access only those MFC objects that it creates. Failure to do so may cause run-time problems including assertions or unexpected program behavior.
More Information
In a Win32 process, all the threads running in the process address space can view all global and static data. A thread can use thread-local-storage (TLS) to store any thread-specific data.
In a multi-threaded environment because windows are owned by threads, MFC keeps the temporary and permanent window handle map in thread local storage. The same is true for other handle maps like those for GDI objects and device contexts. Keeping the window handle maps in thread local storage ensures protection against simultaneous access by several threads.
The behavior of the functions CHandleMap::LookupPermanent() and CHandleMap::LookupTemporary() is a direct consequence of these facts. Given a window handle, these functions check the permanent and temporary window handle maps of the current thread for the existence of an associated CWnd derived MFC object. This means that if calls to these functions are made from a thread to search for MFC objects that represent windows created in other threads, these calls will fail.
There are several functions that call CHandleMap::LookupPermanent() and CHandleMap::LookupTemporary(). CWnd::AssertValid() (and hence the macro ASSERT_VALID for a CWnd object) is one such function. This function is called to make validity checks on an object. If AssertValid() fails to find an entry for the MFC object's m_hWnd member in any of the handle maps or finds an incorrect entry, it fires an assertion. In Visual C++ 2.1, these assertions are in file Wincore.cpp, lines 797 and 798. In Visual C++ 2.2, they are in Wincore.cpp, lines 804 and 805. In Visual C++ 4.0, they are in Wincore.cpp, lines 871 and 872.
Calls to the ASSERT_VALID macro are sprinkled all over the MFC source code. Hence, from a particular thread, if you end up calling a function that calls ASSERT_VALID on MFC window objects that belong to some other thread, you get an assertion. If you do not get an assertion, you may still get abnormal behavior because you are not allowed to directly manipulate windows created by other threads.
The correct approach in such situations is to work with window handles, not MFC objects. It is safe to pass window handles across thread boundaries. If thread A passes a window handle to thread B, then thread B can use this window handle to send or post messages to the window. When these messages are processed, you are back in the context of thread A and calls to CWnd::AssertValid() to check thread A's window handle maps will succeed.
In this scenario, thread B can also use the CWnd::FromHandle() function to get a temporary CWnd object which is placed in thread B's temporary handle map. However this object may be of only limited use, because in no way is it in synchronization with the MFC object existing in thread A's handle maps.
References
MFC Encyclopedia article &Multithreading:Programming Tips& in the Window Handle Maps section.
MFC Tech Note 3 &Mapping of Windows Handles to Objects.&
MFC Source File Wincore.cpp, the function CWnd::AssertValid().
Additional query words: kbinf threads assertion
Keywords: kbMFC kbThread kbVC kbVC200 kbVC210 kbVC220 kbVC400 kbVC410 kbVC420 kbVC500 kbVC600 kbGrpDSMFCATL
Issue Type:
Technology: kbAudDeveloper kbMFC
--------------------------------------------------------------------------------
Send feedback to Microsoft
Microsoft Corporation. All rights reserved.
回复人: YangTze (得分：1) 8:54:35
Re:细细阅读！Knowledge Base&&
HOWTO: Debug MFC Module and Thread State Problems
PSS ID Number: Q189485
Article Last Modified on 07-21-2001
--------------------------------------------------------------------------------
The information in this article applies to:
The Microsoft Foundation Classes (MFC)
Microsoft Visual C++, 32-bit Editions 4.0, 4.1
Microsoft Visual C++, 32-bit Enterprise Edition 4.2
Microsoft Visual C++, 32-bit Professional Edition 4.2
Microsoft Visual C++, 32-bit Enterprise Edition 5.0
Microsoft Visual C++, 32-bit Professional Edition 5.0
--------------------------------------------------------------------------------
MFC maintains three different types of data: process specific data, module specific data, and thread specific data. Because there can be more than one MFC module or thread in a process, MFC maintains state variables to keep track of the current module and thread instance data.
Many ASSERTs can occur when objects are created in the context of one module or thread state, and used or destructed in another. Following are a few common ASSERTs in Visual C++, version 5.0, Service Pack 3:
&& AFXWIN1.INL line 19,&&ASSERT(afxCurrentInstanceHandle != NULL)
&& AFXWIN1.INL line 22,&&ASSERT(afxCurrentResourceHandle != NULL)
&& WINCORE.CPP line 871, ASSERT(pMap != NULL)
&& WINCORE.CPP line 874, ASSERT((p = pMap-&LookupPermanent(m_hWnd)) != NULL
&&&&&&&&&&&&&&&&&&&&&&&&&&&&|| (p = pMap-&LookupTemporary(m_hWnd)) != NULL)
&& WINCORE.CPP line 876, ASSERT((CWnd*)p == this)
More Information
Each MFC module state is tied to an initialization of the shared MFC DLL. The application, as well as each regular MFC DLL and MFC ActiveX control, maintains a separate initialization of MFC. MFC extension DLLs use the module state of the calling application or DLL.
To correctly switch between module states, MFC requires that each entry point contain an AFX_MANAGE_STATE macro that sets and restores the current module state. If an entry point is missing this macro, the current module state can be corrupted. This can result in an ASSERT, general protection fault, or invalid resource being loaded from somewhere else in the process, including inside another MFC DLL.
While thread state is stored in Thread Local Storage (TLS) and is always correct for the running thread, it's still possible to see problems when MFC objects are passed between threads. MFC objects that use Windows or Graphics Device Interface (GDI) handles are stored in thread specific handle maps. When these objects are passed between threads, problems occur.
Below are two macros that you can use to find these problems. You can place them in the stdafx.h file, and use them anywhere in the application or DLL to compare module or thread states:
&& #ifdef _DEBUG
&& #define MODULE_TRACE()&&TRACE(&%s(%d) : Module State nInst = 0x%X\n&, \
&&&&&&&& __FILE__, __LINE__, AfxGetModuleState()-&m_hCurrentInstanceHandle)
&& #define THREAD_TRACE()&&TRACE(&%s(%d) : Thread State Address = 0x%X\n&,\
&&&&&&&& __FILE__, __LINE__, AfxGetThreadState())
&& #define MODULE_TRACE()
&& #define THREAD_TRACE()
&& #endif&&//_DEBUG
Each of these macros prints out a message in the output window, identifying the current module or thread state. Double-clicking on the message takes you to the source line where they appear.
NOTE: you may need to run the MFC Tracer utility from the DevStudio Tools menu, and turn off support for &Multiple application debugging,& as this prepends the module name to the debug string sent to the output window.
MODULE_TRACE() is most useful when you place it in every CWinApp::InitInstance() in the process, as well as where the object that is causing the ASSERTs is being created and destroyed. THREAD_TRACE() works like MODULE_TRACE(), but you should also place it in the CWinThread::InitInstance() of secondary threads.
MODULE_TRACE() returns the same value in every function in the same DLL or .exe file. THREAD_TRACE() returns the same value in every method for a CWnd, or CGdiObject-derived class. If not, there is a problem. You can call the macros more often to help isolate the problem.
Once the problem has been isolated, see the following references on how to fix or resolve the problem.
References
For more information on MFC Module State, please see:
Visual C++ Online Documentation: Microsoft Foundation Class R MFC Technical N TN058: MFC Module State Implementation.
For more information on MFC thread handle maps, please see:
Visual C++ Online Documentation: Visual C++ Programmer's G Adding Program F D Multithreading T click on:
Programming tips for MFC multithreaded programming
For more information on AFX_MANAGE_STATE, search on AFX_MANAGE_STATE in the VC++ 5.0 Online Documentation.
For additional information, please see the following articles in the Microsoft Knowledge Base:
Q127074 How to Use AFX_MANAGE_STATE in an OLE Control
Q140850 HOWTO: Converting DLLTRACE to Use MFC in Shared Library
(c) Microsoft Corporation 1998, All Rights Reserved. Contributions by Kelly Marie Ward, Microsoft Corporation.
Additional query words: Afx AfxModuleState ModuleState AfxThreadState ThreadState
Keywords: kbDebug kbDLL kbMFC kbThread kbVC400 kbVC500 kbGrpDSMFCATL kbArchitecture
Issue Type: kbhowto
Technology: kbAudDeveloper kbMFC
--------------------------------------------------------------------------------
Send feedback to Microsoft
Microsoft Corporation. All rights reserved.
回复人: eplanet (得分：1) 8:54:57
ASSERT(pMap-&LookupPermanent(hWndOrig) == NULL);一个断言，当括号内的条件不满足的时候，就中断程序。Debug下有效。Release就没有用了。
可以根据断言内的条件去推断你的程序的问题。这里的代码太少了。看不出来。
回复人: 阿荣 9:01:55
很多可能啦，例如：一个对象明明已经创建好了你又去创建一次。单靠这个看不出 ，重点看啥函数导致这个问题
回复人: Megan 9:02:43
多谢各位了！！我好像感觉到了些东西，我再仔细理解一下。关于 Debug Assertion Failed的问题
[问题点数：20分，结帖人liangliming2012]
关于 Debug Assertion Failed的问题
[问题点数：20分，结帖人liangliming2012]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
本帖子已过去太久远了，不再提供回复功能。}