错误内容: 微软的错误说明:http://support.microsoft.com/kb/2640103/zh-cn 类似下面的错误: 错误应用程序名称:xxx.exe,版本: 1.0.0.0,时间戳: 0x4f151376 错误模块名称: clr.dll,版本: 4.0.30319.17929,时间戳: 0x4ffa5753 异常代码: 0xc0000005 错误偏移量: 0x0017cbb0 错误进程 ID: 0x11b0 错误应用程序启动时间: 0x01ce21289ba21023 错误

原文网址:http://bbs.zol.com.cn/nbbbs/d160_147794.html 对于经常使用电脑的人来说,比如像最近的我,在晚上总觉得电脑资源管理器屏幕显示得太亮,即使我把电脑的亮度调整为最暗,原因就是因为它的背景色是白色了.win7资源管理器颜色的修改可不是那么简单的事情,百度了许久终于成功修改了背景色,眼睛看得舒服多,特来和大家分享一个shellstyle.dll文件,没有什么技术含量,只为需要的人方便,高手可以无视.先看看效果图: 方法很简单(因为有了做好的shells

 http://www.datazx.cn/Forums/en-US/59aa78c9-dc05-43c8-9efe-e7b132056afc/action?threadDisplayName=windbg-x64-using-sos-failed-to-find-runtime-dll-clrdll 如果我们启动一个 exe 文件从 WinDbg,WinDbg 将中断执行可执行文件之前要运行的另一个词,尚未加载的运行的时间 (clr.dll) :但 SOS 扩展需要 clr.dll (或 ms

问题描述 今天在做项目的时候碰到一个问题,就是用C++编写CLR类库dll的时候,C++的函数参数列表中包含一个char*的输出型参数,然而在C#调用该dll时候,会自动将函数的中的char*参数“翻译”为sbyte*, 使用了各种方法都不能调用函数,主要是不能合适的转换为sbyte*. 简单示例 举个简单的例子,比如我有一个CLR的类库为MyDll.dll, 其中头文件为Mydll.h,简单的只有一个函数,其中我想要为char*的作为输出参数, 代码如下 // MyDll.h #pragma

大家都知道,在调试托管代码时,一定会加载到sos/clr/mscorwks/mscordacwks这些动态库,才能够很好的完成我们的调试工作,那么他们的版本对应关系是怎样的呢,特别是clr.dll/mscorwks.dll有什么关系呢? clr是通用语言运行时库,对应的就是clr.dll/mscorwks.dll,在clr发展过程中,文件名发生了变化,他们的版本对应关系如下: .NET framework 版本 CLR 版本 CLR 文件名 1.1 1.1 mscorwks.dll 2.0 2.

第一次开发wpf程序,就遇到了上述问题,最后发现是因为vs2012默认用的是.net4.5,将版本改为.net4就好了,问题解决

The version of SOS does not match the version of CLR you are debugging 和 PDB symbol for clr.dll not loaded  解决WinDbg调试Dump文件不同环境mscordacwks.dll版本问题 程序发生了崩溃,我抓了一个mini Dump,Mini dump 有一个优点就是非常的小.比full dump 要小很多. 0:020> .loadby sos clr //首先加载sos 0:020>

工作几年了才看,记录下笔记备忘. 章节 笔记 1.CLR的执行模型 公共语言运行时(Common Language Runtime,CLR) 源代码-->编译器检查语法和分析源代码-->托管模块(manged module)(含IL代码)-->运行时有JIT编译器生成cpu指令执行 托管模块由PE32|PE32+(64位).CLR头.元数据.IL代码(中间语言运行时转换成CPU指令) 组成 COM组件是一种规范,实现规范的DLL也可称为COM组件 . 托管模块中的元数据描述了模块中定义了

一.CLR寄宿 .net framework在windows平台的顶部允许.者意味着.net framework必须用windows能理解的技术来构建.所有托管模块和程序集文件必须使用windows PE文件格式,而且要么是windows exe文件,要么是DLL文件 1,MSCorEE.dll(垫片)①CLRCreateInstance函数在MSCorEE.dll文件中实现.“垫片”的工作是决定创建哪个版本的CLR(1.0.2.0.3.0的CLR代码在MSCorWks.dll文件中:版本4则在

#1 CLR寄宿: 开发CLR时,Microsoft实际是将他实现成包含在一个dll中的COM服务器.Microsoft为CLR定义了一个标准的COM接口,并为该接口和COM服务器分配了GUID.安装.NET Framework时,代表CLR的COM服务器在Windows注册表中注册. 任何Windows应用程序都可以寄宿CLR,非托管宿主应该调用MetaHost.h文件中声明的CLRCreateInstance函数,该函数是在MSCoreEE.dll文件中实现的,该dll被称为"垫片"

最近产品环境出现了部分服务器当机情况,虽然重启之后问题就不出现了.但本着彻底解决问题的态度,想要找到root cause.多次尝试Visual Studio失败(可能是代码惊醒了优化和签名)之后,决定使用WinDBG来调试.于是...灾难发生了. 想要一次性成功搭建测试环境,那得靠人品.看来我近来人品积累的不够,不断的有小问题出现.比如加载SOS和CLR,就让我不胜其烦.必须得记下来,分享出来,以节省大家的时间. 问题一:WinDBG分X86和X64两个版本 如果你用的是32位的WinDBG,那

首先写一段代码如下: namespace ConsoleApplication3 { class Program { static void Main(string[] args) { Console.WriteLine("Hello, Windbg!"); Console.ReadKey(); } } } 在Debug目录中启动该程序,然后在Debug中附加该进程. 0:007> .load C:/WINDOWS/Microsoft.NET/Framework/v4.0.303

本系列文章来自 CLR VIA C# .NET FrameWork在Microsoft  Windows平台的顶部运行.这意味着.NET必须用Windows可以理解的技术来构建.首先,所有的托管模块和程序集文件都必须使用Windows PE文件格式,而且要么是一个Windows.exe文件,要么是一个DLL文件. 开发CLR时,Microsoft实际是将它实现成包含在一个DLL中的COM服务器.也就是说,Microsoft为CLR定义了一个标志的COM接口,并为该接口和COM服务器分配了GUID

使用IIS部署站点,报以下错误: Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers. 经排查,发现是引用第三方分页插件mvcpager.dll权限不足造成的,iis服务器设置的权限不足. 在本机通过以下地址:C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Config 打开web.con

WinDBG中加载SOS和CLR 最近产品环境出现了部分服务器当机情况,虽然重启之后问题就不出现了.但本着彻底解决问题的态度,想要找到root cause.多次尝试Visual Studio失败(可能是代码惊醒了优化和签名)之后,决定使用WinDBG来调试.于是...灾难发生了. 想要一次性成功搭建测试环境,那得靠人品.看来我近来人品积累的不够,不断的有小问题出现.比如加载SOS和CLR,就让我不胜其烦.必须得记下来,分享出来,以节省大家的时间. 问题一:WinDBG分X86和X64两个版本 如

一.什么是应用程序域 操作系统由于其稳定性与可靠性的要求,都会使用隔离层,来确保运行在某个隔离层内的代码不会对其他隔扇层的代码产生影响.如Windows通过进程来实现这种隔离机制,所能的可执行代码.数据.以及其它资源都被包含在进程中,系统其他进程通常不允许对它们进行访问.同理..NET应用程序同样也是被局限在进程内执行,但是.NET还进一步引入了另一种逻辑隔离层,也就是我们这里说的应用程序域(AppDomain). 二.如何查看应用程序域 下面用一个例子看看应用程序域: using System

之前看了<用WinDbg探索CLR世界>的一些列文章,发现SOS真的是一个非常好的调试.net的工具, 然后又惊喜的在http://blogs.msdn.com/b/mariohewardt/archive/2012/06/05/visual-studio-2012-and-windbg-integration.aspx 上看到原来windbg已经被集成 到VS2012的IDE中.本文主要讲解在VS2012中调用SOS的基本步骤 1 SOS是一个非托管的DLL,要使用SOS调试,首先需要打开本

当运行Windows应用程序的时候,CLR总是默默地为服务着.CLR到底是如何被加载并运行呢? 首先,Microsoft专门为CLR定义了一个标准的COM接口. 安装某个版本的.NET Framework,CLR被包含在DLL中,作为COM服务器在Windows注册表中注册. 一台电脑上可能安装多个版本的CLR.打开开发人员命令提示,输入CLRVer.exe,可以看到当前电脑上安装的CLR版本. 比如,在C:\Windows\Microsoft.NET\Framework\v2.0.50727文

这是一个老话题,远线程函数给我们提供了机会在其他进程中启动一个新线程,所以我们可以做很多事情.但事情远远没有结束,如果我们要做的事情非常复杂,那么将面临编写大量的ASM代码,虽然我们可以用VC之类的工具编译一个简短的函数然后抄袭它.所以,我们经常做的是把我们的要做的放入一个DLL,而远线程所做的只是调用LoadLibrary函数来加载我们的DLL,这只需要少量的ASM甚至可以不用ASM. 如果我们要注入一个标准的WINDOWS DLL文件,无论目标进程是不是托管的事情往往很简单,但是如果注入托管

解决WinDbg调试Dump文件不同环境mscordacwks.dll版本问题   开发人员提交一个dump文件(Windows Server 2008 R2),当前调试环境Windows Server 2012,加载sos.dl执行~* e !clrstack,提示如下错误: Failed to load data access DLL, 0x80004005 Verify that 1) you have a recent build of the debugger (6.2.14 or n