2010.1.1 CLR 无法从 COM 上下文

今天做一个程序,sql操作,但是记录数太多,而且sql语句有复杂,就报了这样的错误:

CLR 无法从 COM 上下文 0x645e18 转换为 COM 上下文 0x645f88,这种状态已持续 60 秒。拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作。

这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积。

要避免此问题,所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMultipleHandles),并在运行时间很长的操作过程中定期发送消息。

解决方法是 在Debug -> Exceptions -> Managed Debug Assistants里 去掉ContextSwitchDeadlock一项前面的钩。解决生成word文件不规律报错文件键sdp/p3页尾说明。

时间: 2024-10-05 05:00:24

2010.1.1 CLR 无法从 COM 上下文的相关文章

CLR 无法从 COM 上下文 0x208f68 转换为 COM 上下文 0x2090d8,这种状态已持续 60 秒。

CLR 无法从 COM 上下文 0x208f68 转换为 COM 上下文 0x2090d8,这种状态已持续 60 秒.拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积.要避免此问题,所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMultipleHandles),并在运行时间很长的操作过程中定期发送消息当网速卡的时候就

异常信息:CLR无法从COM 上下文0x645e18 转换为COM上下文0x645f88,这种状态已持续60秒。拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的

异常原因: 1.写了一个死循环,这个可能性最大. 2.进行大数据量的运算,导致假死状况. 解决办法:Debug -> Exceptions -> Managed Debug Assistants里 去掉ContextSwitchDeadlock一项前面的钩.

检测到 ContextSwitchDeadlock

错误信息 检测到 ContextSwitchDeadlock Message: CLR 无法从 COM 上下文 0x622b440 转换为 COM 上下文 0x622b5b0,这种状态已持续 60 秒.拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积.要避免此问题,所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMul

C++/CLI学习入门

托管是.NET的一个专门概念,它倡导一种新的编程理念,因此我们完全可以把“托管”视为“.NET”.C++托管扩展(Managed Extension for C++,即MC++)是微软为了让Visual C++可以支持托管的引用程序的开发而对传统C++语言进行的扩展,是新一代Visual C++开发工具的语言核心.对Microsoft Visual C++语言进行扩展可以生成.NET代码,这些扩展称为C++.NET托管扩展.C++是惟一一种可以在同一个源文件中混合.NET代码和非托管代码的语言,

解决c#所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMultipleHandles),并在运行时间很长的操作过程中定期发送消息。 转载

最近做一个后来程序,启动了事务后有一段操作业务,当运行一段时间后,出现这个异常 CLR 无法从 COM 上下文 0x1b1c38 转换为 COM 上下文 0x1b1da8,这种状态已持续 60 秒.拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积.要避免此问题,所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMulti

泵式等待基元

其他信息: CLR 无法从 COM 上下文 0x88e028 转换为 COM 上下文 0x88e0e0,这种状态已持续 60 秒.拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积.要避免此问题,所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMultipleHandles),并在运行时间很长的操作过程中定期发送消息.=

C/S端开发问题汇总

0.先推荐几款工具,连接远程客户端DameWare Mini Remote Control,搜索本地文件Everything,以及sysinternals的系列工具: FileMon-监视所有文件修改.RegMon-监视所有注册表修改.ProcessExplorer-任务管理器.ProcessMonitor-监视进程对文件+注册表的所有操作 SigCheck-识别文件头+签名+对应的pbd.TcpView-监视所有tcp连接.PsTools系列工具-操作所有本地+远程进程 1.在一些基于Serv

单线程单元(STA)线程都应使用泵式等待基元

CLR 无法从 COM 上下文 0x20ad98 转换为 COM 上下文 0x20af08,这种状态已持续 60 秒.拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积.要避免此问题,所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMultipleHandles),并在运行时间很长的操作过程中定期发送消息 解决方法 ct

批处理上传错误

CLR 无法从 COM 上下文 0x622b440 转换为 COM 上下文 0x622b5b0,这种状态已持续 60 秒.拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积.要避免此问题,所有单线程单元(STA)线程都应使用泵式等待基元(如 CoWaitForMultipleHandles),并在运行时间很长的操作过程中定期发送消息. mysq