KernelBase.dll exception code 0x0EEDFADE (but no crash) when Visual Studio is NOT run as administrator (GLFW/glad application)

Question

I'm using Visual Studio 2019 and have the following simple OpenGL program as a minimal example (using GLFW and 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();
}

The program works fine but while it's running I get lines like those who follow in the debug output window in intervals of few to around 20 or even more seconds:

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).

The program keeps running though, works fine and also exits with exit code 0. It also works fine when I execute the EXE file outside of Visual Studio. When I set VS to break on all exceptions, then I see that the exception occurs in this call (win32_init.c, "createHelperWindow" method):

_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);

I already spent hours on Google trying to find a solution to this. The only "hint" I got is that the exceptions do not occur when I run VS19 as administator. Does someone have an idea what's causing this? Or should I just ignore it since it runs fine? That'd feel wrong though....

Update/Solution

I followed the tips in Ben's answer (see accepted answer). After enabling breaking on first-chance exceptions, I got the following stack trace:

The DLL "ammemb64.dll" also appeared in the modules window. It belongs to the software "Actual Multiple Monitors" and after closing that application, the exception was gone.

Answer 1

According to Google, that's the OS exception (structured exceptions) code used by Delphi. Since you aren't writing in Delphi, it's likely some program written in Delphi is hooking into all running processes. When you run in admin mode, your process is sufficiently privileged that the hook can't touch it.

If you want to find the culprit, enable that exception code as first-chance ("Break when thrown" not just if uncaught) in the Visual Studio Exceptions dialog (right-click on the entry "Win32 Exceptions" and choose Add, then you will be able to have an entry for 0x0EEDFADE). And look at the stack trace, almost certainly the call to kernelbase.dll is coming through some third-party DLL.

You may also get clues by looking at the Modules list in Visual Studio while debugging, to see what DLLs are loaded into your process that are not related to the OS or the C++ runtime. Probably the pathname of the DLL will be a dead giveaway.

Here's an existing question where an unknown (but different) exception occurred during a CreateWindow call, also as a result of a hook DLL: Create CFrameWnd gives first-chance exceptions--why?

In particular I agree with every word of the comment that @IInspectable left on that question:

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.

Here's yet another instance of the same problem of a hook causing exceptions: first chance exception in standard win32 wndproc