0x0000006B 装win7时出现

Posted 2023-05-15

我是用深度的win7的盗版装的。 第一次装好以后，运气看起来很正常。 但是启动第2次后就会出现花屏，或者蓝屏的现象。我重装一次后，出现蓝屏没有花屏，不知道是怎么因为，请高手指教

导致出现0x0000006B代码的原因是系统启动文件丢失导致的。
解决方法如下：
一、找一张带有WindowsPE（预安装环境），进入系统后，打开C:\\Windows\\System32\\Codeintegrity\\文件夹（C:\\对应Windows7安装分区）。这个文件夹中有两个件：bootcat.cache和driver.stl。
二、请查看bootcat.cache文件的属性，在我这个正常的x64系统中此文件大小是4.74MB，如果该文件大小太小，就有问题了，蓝屏与这个有关系。直接将bootcat.cache这个文件删除即可正常进入系统。
补充一点：如果有一个正常的Windows 7系统的话，将C:\\Windows\\System32\\catroot\\F750E6C3-38EE-11D1-85E5-00C04FC295EE\\整个文件夹复制到有问题的电脑上覆盖原文件夹，可以彻底解决问题 参考技术A 0x0000006B:PROCESS1_INITIALIZATION_FAILED
◆错误分析:如果您的计算机上安装了 Roxio GoBack 程序，则可能会发生此问题。
GoBack 程序还包括在 Norton SystemWorks 程序中。
◇解决方案:请取消 Windows XP 安装程序，删除 GoBack，然后重新启动 Windows XP 安装程序。
请在 Windows XP 安装程序重新启动计算机时禁用 GoBack 程序：
警告 如果您禁用 GoBack，所有与 GoBack 程序相关的历史信息都将丢失，并且您不能够使用 GoBack 程序将计算机恢复到以前的状态。
(1)重启计算机，然后在收到 GoBack "Press SPACEBAR to repair problems or see other boot options" 消息后按空格键。
(2)在“GoBack Boot”（GoBack 启动）菜单上，单击“Disable GoBack”（禁用 GoBack），然后单击“继续”。
(3)单击“是”以禁用 GoBack。
(4)在禁用 GoBack 之后，单击“确定”，然后单击“继续”。本回答被提问者采纳

在 C++（win32 应用程序）中使用 C# 类时出现 EEFileLoadException

【中文标题】在 C++（win32 应用程序）中使用 C# 类时出现 EEFileLoadException

【英文标题】：EEFileLoadException when using C# classes in C++(win32 app)

【发布时间】：2008-09-18 15:49:31

【问题描述】：

出于部署原因，我尝试使用 IJW 在 C++ 中包装 C# 程序集，而不是使用 COM 可调用包装器。

我在其他项目上也做过，但在这个项目上，我得到了一个 EEFileLoadException。任何帮助将不胜感激！

托管 C++ 包装代码（在 DLL 中）：

extern "C" __declspec(dllexport) IMyObject* CreateMyObject(void)

    //this class references c# in the constructor
    return new CMyWrapper( );


extern "C" __declspec(dllexport)  void DeleteMyObject(IMyObject* pConfigFile)

    delete pConfigFile;


extern "C" __declspec(dllexport) void TestFunction(void)

    ::MessageBox(NULL, _T("My Message Box"), _T("Test"), MB_OK);

测试代码（这是一个EXE）：

typedef void* (*CreateObjectPtr)();
typedef void (*TestFunctionPtr)();

int _tmain testwrapper(int argc, TCHAR* argv[], TCHAR* envp[])

    HMODULE hModule = ::LoadLibrary(_T("MyWrapper"));
    _ASSERT(hModule != NULL);

    PVOID pFunc1 = ::GetProcAddress(hModule, "TestFunction");
    _ASSERT(pFunc1 != NULL);
    TestFunctionPtr pTest = (TestFunctionPtr)pFunc1;

    PVOID pFunc2 = ::GetProcAddress(hModule, "CreateMyObject");
    _ASSERT(pFunc2 != NULL);
    CreateObjectPtr pCreateObjectFunc = (CreateObjectPtr)pFunc2;

    (*pTest)();  //this successfully pops up a message box
    (*pCreateObjectFunc)();  //this tosses an EEFileLoadException

    return 0;

对于它的价值，事件日志报告以下内容： .NET 运行时版本 2.0.50727.143 - 致命的执行引擎错误 (79F97075) (80131506)

很遗憾，Microsoft 没有关于该错误的信息。

【问题讨论】：

您是否进行了测试来验证程序集是否从同一目录加载？

当我手动将托管 DLL 复制到 exe 的目录中时，它可以在没有这些额外代码的情况下工作。

【参考方案1】：

问题在于 DLL 的位置。

c:\dlls\managed.dll c:\dlls\wrapper.dll c:\exe\my.exe

我通过将 managed.dll 复制到 c:\exe 中确认了这一点，它可以正常工作。显然，CLR 不会在非托管 DLL 的路径中查找托管 DLL，而只会在可执行文件所在的位置查找它。 （或在 GAC 中）。

出于不值得讨论的原因，这是我需要的结构，这意味着我需要让 CLR 帮助定位托管 dll。见以下代码：

AssemblyResolver.h：

/// <summary>
/// Summary for AssemblyResolver
/// </summary>
public ref class AssemblyResolver

public:

static Assembly^ MyResolveEventHandler( Object^ sender, ResolveEventArgs^ args )

    Console::WriteLine( "Resolving..." );

    Assembly^ thisAssembly = Assembly::GetExecutingAssembly();
    String^ thisPath = thisAssembly->Location;
    String^ directory = Path::GetDirectoryName(thisPath);
    String^ pathToManagedAssembly = Path::Combine(directory, "managed.dll");

    Assembly^ newAssembly = Assembly::LoadFile(pathToManagedAssembly);
    return newAssembly;


;

包装器.cpp：

#include "AssemblyResolver.h"

extern "C" __declspec(dllexport) IMyObject* CreateMyObject(void)

    try
    
        AppDomain^ currentDomain = AppDomain::CurrentDomain;
        currentDomain->AssemblyResolve += gcnew ResolveEventHandler( AssemblyResolver::MyResolveEventHandler );

        return new CMyWrapper( );
    
    catch(System::Exception^ e)
    
        System::Console::WriteLine(e->Message);

        return NULL;
    

【讨论】：

我花了好几个小时试图弄清楚我的混合 DLL 出了什么问题，结果却发现它抛出了一个 EEFileLoadException。谢谢你，它帮助了:)

【参考方案2】：

第一个问题是确保调试器类型设置为混合。然后你会得到有用的异常。

【讨论】：

我遇到了他用托管 C++ 编写的 Excel 插件的问题，实际上我发现在混合调试中我得到 less 有用的异常；特别是我没有看到 EEFileLoadException 本身，只是随后的几次重新抛出。

这个建议可能为我节省了一个小时的调试时间。

【参考方案3】：

对于使用混合模式 dll（您的 EXE）的本机应用程序，请将 **“调试器类型”更改为“混合”模式。 （进入项目属性 -> 配置属性 -> 调试）

还有一些其他点（可能与您无关），但根据我的经验，它们可能会导致问题。 - 在 Windows 8（具有更严格的安全性）上，请尝试以管理员身份启动您的 VS。 - 确保对于 x86 配置，您使用的是 x86 二进制文件。 - 注意 StrongName 验证，如果您在托管 C++ 中使用的 C# 程序集已签名，请考虑对混合模式 dll 进行签名。

希望这会有所帮助。

【讨论】：

这为我解决了问题！现在我可以看到实际的错误...谢谢！

【参考方案4】：

如果其他人偶然发现了这个问题，并且您使用的是动态程序集名称：请确保您剥离了程序集名称，它可能包含您可能不会使用的版本、文化和其他内容。

即，您的 MyResolveEventHandler 应采用以下形式：

static Assembly^ MyResolveEventHandler( Object^ sender, ResolveEventArgs^ args )

    Console::WriteLine( "Resolving..." );

    String^ assemblyName = args->Name;

    // Strip irrelevant information, such as assembly, version etc.
    // Example: "Acme.Foobar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
    if( assemblyName->Contains(",") ) 
    
        assemblyName = assemblyName->Substring(0, assemblyName->IndexOf(","));
    

    Assembly^ thisAssembly = Assembly::GetExecutingAssembly();
    String^ thisPath = thisAssembly->Location;
    String^ directory = Path::GetDirectoryName(thisPath);
    String^ pathToManagedAssembly = Path::Combine(directory, assemblyName );

    Assembly^ newAssembly = Assembly::LoadFile(pathToManagedAssembly);
    return newAssembly;

【参考方案5】：

在调试 ASP.NET MVC 应用程序期间，iisexpress.exe 经常抛出 C++ EEFileLoadException。调用堆栈和 C++ 异常本身对于帮助我解决问题并没有太大帮助。

在直接查看 C++ 异常中给出的指针地址后，我最终发现了一个库字符串，它指向不再使用的旧版本。这反过来又是由于我的 web.config 文件中的一个过期条目：

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Security.OAuth" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
  </dependentAssembly> </assemblyBinding> </runtime>

我已通过 NuGet 将各种 Microsoft.Own 安全库升级到版本 4.0.30319，但配置中的这一行指示服务器将调用重定向到版本 3.0.1.0，现在不再是我项目的一部分。更新配置解决了我的问题。

【参考方案6】：

当您在使用 C++ 托管 dll 的调试器 C++ 本机项目中运行时，您可能会遇到此异常。当 VS2010 捕获它并且您的应用程序在某些链异常之后将被中止时，您可以尝试在异常过滤器（菜单|调试|异常）中禁用所有 C++ 异常。您仍会在输出中看到此异常，但您的应用程序不会中止

【讨论】：

-1：这似乎是一个不解决问题的坏建议