KernelBase.dll 异常代码 0x0EEDFADE（但没有崩溃）当 Visual Studio 不是 运行 作为管理员（GLFW/glad 应用程序）
KernelBase.dll exception code 0x0EEDFADE (but no crash) when Visual Studio is NOT run as administrator (GLFW/glad application)
我正在使用 Visual Studio 2019 并使用以下简单的 OpenGL 程序作为最小示例（使用 GLFW 和 GLAD）：
#include <iostream>
#include <glad/glad.h>
#include <GLFW/glfw3.h>
void error_callback(int error, const char* description) {
std::cout << "GLFW error: " << description << " (" << error << ")\n";
}
int main() {
if (!glfwInit()) exit(-1);
glfwSetErrorCallback(error_callback);
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
GLFWwindow* window = glfwCreateWindow(640, 480, "GLFW Test Application", nullptr, nullptr);
if (!window) exit(-1);
glfwMakeContextCurrent(window);
if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)) exit(-1);
glViewport(0, 0, 640, 480);
glClearColor(0.6f, 0.6f, 0.1f, 1.f);
while (!glfwWindowShouldClose(window)) {
glClear(GL_COLOR_BUFFER_BIT);
glfwSwapBuffers(window);
glfwPollEvents();
}
glfwDestroyWindow(window);
glfwTerminate();
}
程序运行良好，但在 运行ning 期间，我得到的行与调试输出 window 中的行类似，间隔为几秒到大约 20 秒甚至更长：
Exception thrown at 0x00007FFE61EEA799 (KernelBase.dll) in vcpkg_test.exe: 0x0EEDFADE (parameters: 0x0000000001D0A34E, 0x000001C13E322BA0, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).
Exception thrown at 0x00007FFE61EEA799 (KernelBase.dll) in vcpkg_test.exe: 0x0EEDFADE (parameters: 0x0000000001D0A34E, 0x000001C13DC7CE40, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).
Exception thrown at 0x00007FFE61EEA799 (KernelBase.dll) in vcpkg_test.exe: 0x0EEDFADE (parameters: 0x0000000001D0A34E, 0x000001C13DC7CDE0, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).
虽然程序保持 运行ning，工作正常并且退出代码为 0。当我在 Visual Studio 之外执行 EXE 文件时它也工作正常。当我设置 VS 在 all 异常时中断，然后我看到异常发生在这个调用中（win32_init.c，"createHelperWindow" 方法）：
_glfw.win32.helperWindowHandle =
CreateWindowExW(WS_EX_OVERLAPPEDWINDOW,
_GLFW_WNDCLASSNAME,
L"GLFW message window",
WS_CLIPSIBLINGS | WS_CLIPCHILDREN,
0, 0, 1, 1,
NULL, NULL,
GetModuleHandleW(NULL),
NULL);
我已经花了几个小时 Google 试图找到解决这个问题的方法。我得到的唯一 "hint" 是当我 运行 VS19 作为管理员时 不会 发生异常。
有人知道是什么原因造成的吗？还是我应该忽略它，因为它 运行 没问题？但这感觉不对....
Update/Solution
我遵循了 Ben 的回答中的提示（参见已接受的回答）。启用中断第一次机会异常后，我得到了以下堆栈跟踪：
DLL "ammemb64.dll" 也出现在模块 window 中。它属于软件 "Actual Multiple Monitors"，关闭该应用程序后，异常消失。
根据Google，这是Delphi使用的OS异常（结构化异常）代码。由于您不是用 Delphi 编写的，所以很可能某些用 Delphi 编写的程序挂接到所有 运行ning 进程中。当您 运行 处于管理员模式时，您的进程有足够的特权，钩子无法触及它。
如果您想找到罪魁祸首，请在 Visual Studio 异常对话框（右键单击条目 "Win32 Exceptions" 并选择添加，然后您将能够拥有 0x0EEDFADE) 的条目。并查看堆栈跟踪，几乎可以肯定对 kernelbase.dll 的调用是通过某些第三方 DLL 进行的。
您还可以通过在调试时查看 Visual Studio 中的模块列表来获得线索，以查看哪些 DLL 加载到您的进程中与 OS 或 C++ 运行时间。可能 DLL 的路径名将是一个死赠品。
这是一个现有问题，在 CreateWindow 调用期间发生未知（但不同）异常，也是挂钩 DLL 的结果：Create CFrameWnd gives first-chance exceptions--why?
特别是我同意@IInspectable 就该问题发表的评论中的每一个字：
This is likely an effect caused by an application running in your desktop, that installs a global hook or causes code to run in your process using other infrastructure. Inside the handler an exception is raised, and later caught (otherwise you'd see a second-chance exception, together with an uncaught exception dialog). To solve this you'd have to identify the faulting application, and remove it from your system. Other than that, there's nothing wrong with your code.
这里是钩子导致异常的相同问题的另一个实例：first chance exception in standard win32 wndproc
我正在使用 Visual Studio 2019 并使用以下简单的 OpenGL 程序作为最小示例（使用 GLFW 和 GLAD）：
#include <iostream>
#include <glad/glad.h>
#include <GLFW/glfw3.h>
void error_callback(int error, const char* description) {
std::cout << "GLFW error: " << description << " (" << error << ")\n";
}
int main() {
if (!glfwInit()) exit(-1);
glfwSetErrorCallback(error_callback);
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
GLFWwindow* window = glfwCreateWindow(640, 480, "GLFW Test Application", nullptr, nullptr);
if (!window) exit(-1);
glfwMakeContextCurrent(window);
if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)) exit(-1);
glViewport(0, 0, 640, 480);
glClearColor(0.6f, 0.6f, 0.1f, 1.f);
while (!glfwWindowShouldClose(window)) {
glClear(GL_COLOR_BUFFER_BIT);
glfwSwapBuffers(window);
glfwPollEvents();
}
glfwDestroyWindow(window);
glfwTerminate();
}
程序运行良好，但在 运行ning 期间，我得到的行与调试输出 window 中的行类似，间隔为几秒到大约 20 秒甚至更长：
Exception thrown at 0x00007FFE61EEA799 (KernelBase.dll) in vcpkg_test.exe: 0x0EEDFADE (parameters: 0x0000000001D0A34E, 0x000001C13E322BA0, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).
Exception thrown at 0x00007FFE61EEA799 (KernelBase.dll) in vcpkg_test.exe: 0x0EEDFADE (parameters: 0x0000000001D0A34E, 0x000001C13DC7CE40, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).
Exception thrown at 0x00007FFE61EEA799 (KernelBase.dll) in vcpkg_test.exe: 0x0EEDFADE (parameters: 0x0000000001D0A34E, 0x000001C13DC7CDE0, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).
虽然程序保持 运行ning，工作正常并且退出代码为 0。当我在 Visual Studio 之外执行 EXE 文件时它也工作正常。当我设置 VS 在 all 异常时中断，然后我看到异常发生在这个调用中（win32_init.c，"createHelperWindow" 方法）：
_glfw.win32.helperWindowHandle =
CreateWindowExW(WS_EX_OVERLAPPEDWINDOW,
_GLFW_WNDCLASSNAME,
L"GLFW message window",
WS_CLIPSIBLINGS | WS_CLIPCHILDREN,
0, 0, 1, 1,
NULL, NULL,
GetModuleHandleW(NULL),
NULL);
我已经花了几个小时 Google 试图找到解决这个问题的方法。我得到的唯一 "hint" 是当我 运行 VS19 作为管理员时 不会 发生异常。 有人知道是什么原因造成的吗？还是我应该忽略它，因为它 运行 没问题？但这感觉不对....
Update/Solution
我遵循了 Ben 的回答中的提示（参见已接受的回答）。启用中断第一次机会异常后，我得到了以下堆栈跟踪：
DLL "ammemb64.dll" 也出现在模块 window 中。它属于软件 "Actual Multiple Monitors"，关闭该应用程序后，异常消失。
根据Google，这是Delphi使用的OS异常（结构化异常）代码。由于您不是用 Delphi 编写的，所以很可能某些用 Delphi 编写的程序挂接到所有 运行ning 进程中。当您 运行 处于管理员模式时，您的进程有足够的特权，钩子无法触及它。
如果您想找到罪魁祸首，请在 Visual Studio 异常对话框（右键单击条目 "Win32 Exceptions" 并选择添加，然后您将能够拥有 0x0EEDFADE) 的条目。并查看堆栈跟踪，几乎可以肯定对 kernelbase.dll 的调用是通过某些第三方 DLL 进行的。
您还可以通过在调试时查看 Visual Studio 中的模块列表来获得线索，以查看哪些 DLL 加载到您的进程中与 OS 或 C++ 运行时间。可能 DLL 的路径名将是一个死赠品。
这是一个现有问题，在 CreateWindow 调用期间发生未知（但不同）异常，也是挂钩 DLL 的结果：Create CFrameWnd gives first-chance exceptions--why?
特别是我同意@IInspectable 就该问题发表的评论中的每一个字：
This is likely an effect caused by an application running in your desktop, that installs a global hook or causes code to run in your process using other infrastructure. Inside the handler an exception is raised, and later caught (otherwise you'd see a second-chance exception, together with an uncaught exception dialog). To solve this you'd have to identify the faulting application, and remove it from your system. Other than that, there's nothing wrong with your code.
这里是钩子导致异常的相同问题的另一个实例：first chance exception in standard win32 wndproc