这个过程在Windows 7中崩溃了。我在WinDbg使用!analyze -v命令进行exception分析。 它告诉下面的信息。 exception实际上是由IRSSim!irsNet_BlockOutput调用的WaitForSingleObject函数引发的。 WinDbg的exception分析告诉我这是INVALID_POINTER_READ错误。
对于调用代码， pChannel->hMutex不是NULL 。 我已经把它甩了，检查了它的价值。
irsNETRET irsNet_BlockOutput( irsNET *pChannel) { // Check channel irsNET_CHECK_CHANNEL(pChannel); // Wait for synchronization mutex switch(WaitForSingleObject(pChannel->hMutex,INFINITE)) { ... }
<<<<< ==========
FAULTING_IP：IRSSim！Channel :: SendirsMessage + 285 [s： som5 ics scsv isv test.u iRSSim irsiftransport.cpp @ 539] 00520ed5 8b06 mov eax，dword ptr [esi]
Windows错误：exception：访问冲突读取0x00000160
我可以让Visual Studio在用户定义的C ++exception中断开吗？
在Qt应用程序中的C ++崩溃/exception处理程序，在Windows上有线程支持
debugging器主循环
在Linux中的exception处理
EXCEPTION_RECORD：ffffffff – （.exr 0xffffffffffffffff）ExceptionAddress：77db4639（ntdll！RtlDeactivateActivationContextUnsafeFast + 0x00000058）
ExceptionCode：c0150010 ExceptionFlags：00000001 NumberParameters：3参数[0]：00000000参数[1]：07befc58参数[2]：00000000
DEFAULT_BUCKET_ID：INVALID_POINTER_READ
PROCESS_NAME：IRSSim.exe
ERROR_CODE：（NTSTATUS）0xc0150010 – 当前正在执行的线程未激活激活上下文。
EXCEPTION_CODE：（NTSTATUS）0xc0150010 – 当前正在执行的线程未激活激活上下文。
EXCEPTION_ParaMETER1：00000000
EXCEPTION_ParaMETER2：07befc58
EXCEPTION_ParaMETER3：00000000
STACK_TEXT：！！！！！07d2fce0 00520ed5 iRSSim频道:: SendirsMessage + 0x285 07d2fd1c 00521072 iRSSim CChannelArray :: SendirsMessage + 0x132 07d2fd50 0052208a iRSSim CNetLibInterface :: SendirsMessage + 0xba 07d2fd78 005c01b6 iRSSim CSendActivity ::执行+ 0x76 07d2fdac 005e0b3f iRSSim SimulationThreadState :: ExecuteOneActivity + 0x11f 07d2fdf8 005cc937 iRSSim！CSimulationSubThreadState :: ExecuteState + 0x267 07d2fe8c 005ccf02 iRSSim！ThreadFctSubSimulation + 0xf2 07d2fec4 73b1e3ee mfc90u！_AfxThreadEntry + 0xf2 07d2ff4c 739f3433 msvcr90！_endthreadex + 0x44进行07d2ff84 739f34c7 msvcr90！_endthreadex + 0xd8 07d2ff90 767d339a KERNEL32！BaseThreadInitThunk + 0xe 07d2ff9c 77d69ed2 NTDLL ！__ RtlUserThreadStart + 0x70 07d2ffdc 77d69ea5 ntdll！_RtlUserThreadStart + 0x1b
================================
之后，我使用！teb命令尝试获取更多堆栈信息。
0：011>ķL = 07beec2c 100 ChildEBP RetAddr 07bef54c 76be0bdd NTDLL NtWaitForMultipleObjects + 0×15 07bef5e8 767d1a2c KERNELBASE WaitForMultipleObjectsEx + 0x100的07bef630 767d4208 KERNEL32 WaitForMultipleObjectsExImplementation + 0xe0的07bef64c 767f80a4 KERNEL32 WaitForMultipleObjects的+为0x18 07bef6b8 767f7f63 KERNEL32 WerpReportFaultInternal + 0x186 07bef6cc 767f7858 KERNEL32！！！ WerpReportFault + 0x70 07bef6dc 767f77d7 KERNEL32！BasepReportFault + 0×20 07bef768 77da21d7 KERNEL32！UnhandledExceptionFilter的+ 0x1af 07bef770 77da20b4 NTDLL！__ RtlUserThreadStart + 0X62 07bef784 77da1f59 NTDLL！_EH4_CallFilterFunc + 0×12 07bef7ac 77d76ab9 NTDLL！_except_handler4 +为0x8E 07bef7d0 77d76a8b NTDLL！ExecuteHandler2 + 0×26 07bef7f4 77d76a2d NTDLL！ExecuteHandler + 0x24 07bef880 77d40143 ntdll！RtldispatchException + 0x127 07bef880 77db4639 ntdll！KiUserExceptiondispatcher + 0xf 07befc34 76be0ad7 ntdll！RtlDeactivateActivationContextUnsafeFast + 0x58 07befc38 76be0abc KERNELBASE！WaitForSingleObjectEx + 0xde 07befc98 767d1194 KERNELBASE！WaitForSingle ObjectEx + 0xc3 07befcb0 767d1148 kernel32！WaitForSingleObjectExImplementation + 0x75
07befcc4 005e3b6e kernel32！WaitForSingleObject + 0x12
07befcd4 00520d3b IRSSim！irsNet_BlockOutput + 0x1e
07befd14 00521072 IRSSim！Channel :: SendirsMessage + 0xeb 07befd48 0052208a IRSSim！CChannelArray :: SendirsMessage + 0x132 07befd70 005c01b6 IRSSim！CNetLibInterface :: SendirsMessage + 0xba 07befda4 005e0b3f IRSSim！CSendActivity :: Execute + 0x76 07befdf0 005cc937 IRSSim！SimulationThreadState :: ExecuteOneActivity + 0x11f 07befe84 005ccf02 IRSSim！CSimulationSubThreadState :: ExecuteState + 0x267 07befebc 73b1e3ee IRSSim！ThreadFctSubSimulation + 0xf2 07beff44 739f3433 mfc90u！_AfxThreadEntry + 0xf2 07beff7c 739f34c7 msvcr90！_endthreadex + 0x44进行07beff88 767d339a msvcr90！_endthreadex + 0xd8 07beff94 77d69ed2 KERNEL32！BaseThreadInitThunk + 0xe 07beffd4 77d69ea5 NTDLL！__ RtlUserThreadStart + 0x70 07beffec 00000000 ntdll！_RtlUserThreadStart + 0x1b
==================================== >>>>>>
Python：获取WindowsError而不是IOError
是否有可能在Windows上捕获另一个进程的未处理的exception？
为什么MemoryStream.GetBuffer（）总是抛出？
在这个exception消息中引用了什么“配额”：没有足够的配额可用于处理此命令
Windows DataGridView BindingSource索引超出范围的exception
这看起来很像在MFC应用程序中遇到的0xC015000f异常（“正在取消激活的激活上下文不是最近激活的激活上下文”）。
在我遇到这个例外的所有情况下，例外不是主要问题。 这是一个较早的异常的副作用，通常是访问冲突，堆栈没有正确解除。 在异常处理中丢失了使用宏（如AFX_MANAGE_STATE宏）的调用帧。 结果是，下一次激活上下文被操纵时，例如由另一个例程导致对AFX_MAINTAIN_STATE2 ::〜AFX_MAINTAIN_STATE2的调用，系统检测到Cookie不匹配并抛出异常。
在你的情况下，你可能会导致一个异常（最有可能是一个AV）在一段代码，然后表现为上下文异常。 要捕获根本原因，请在启用第一次机会异常处理的情况下运行调试器。 这样一来，被某个人或许使用一个try / catch（…）被困在其他地方的AV将被暴露。 由于您似乎是线程化的，因此您可能只是在导致主要异常（如果确实发生了这种情况）的内存访问方面存在争用条件。
我在之前的文章中看到：“实际上，这个问题来自将程序从64位的Win XP移植到64位的Win7，编译器从VC6切换到VC9。
这不是MFC中的错误。 MFC 6不包括在Visual Studio 2005中添加的激活上下文切换代码（这是基于cookie的），所以你不会遇到这个异常。 我们也认为新的MFC有问题，但在任何情况下，我们遇到了，这是我们的代码，导致了这个问题。 原始问题被代码流所掩盖，这些代码流以try / catch（通常是…）开头，最终调用的代码使用了MFC管理状态宏之一，然后调用更多的代码，最终AV会发生。 由于捕获是堆栈，并根据腐败，并不是所有的帧都正确解开，MFC宏的背面被遗漏（某些析构函数未能弹出其上下文）。 更糟糕的是（为了调试），最终的上下文崩溃可能发生在你的代码中的任何地方（我们在CWnd的基本窗口消息处理路由方法中经历了很多）。 我们最终创建了另一个用户运行的工具，它将自己作为调试器附加到我们的（释放目标）可执行文件中，该可执行文件捕获了第一次机会异常，并创建了一个dmp文件，以便我们可以找到发生异常的初始点，上下文异常几乎从来没有用，因为问题的原始来源是过去执行很久以来。
这种通话唯一的方式就是如果失败
pChannel->hMutex
是无效的。 pChannel本身是hMutex ，或hMutex 。 最有可能的是前者。
你应该检查句柄是否无效，而不是简单地不为NULL ：
if (myHandle != INVALID_HANDLE_VALUE) { // do something }
通常，如果出现错误，create handle函数将返回此值。
看起来像在上下文停用问题（基于windbg转储的想法）。 请参阅http://blogs.msdn.com/b/junfeng/archive/2006/03/19/sxs-activation-context-activate-and-deactivate.aspx文章。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
