Problem Statement/Rationale

Compass 1.49.12 fails to start on Windows machines where Smart App Control (or a similarly strict WDAC policy) is enabled: the process tree spawns (main + crashpad + GPU + network utility) but no window ever appears and no Compass log file is written to %LOCALAPPDATA%\mongodb\compass. Repeated launch attempts accumulate windowless zombie processes. Reboot, clean MSI reinstall, and full profile/cache resets do not help. Compass worked the previous day on the same machine; the failure began when Smart App Control's cloud reputation verdict for the unsigned module flipped to "block".

Root cause: node_modules/native-machine-id/build/Release/native_machine_id.node ships unsigned. Smart App Control blocks loading unsigned DLLs. Attaching the Node inspector to the main process and registering an unhandledRejection handler surfaces the swallowed startup error:

Error: An Application Control policy has blocked this file.
\\?\C:\Program Files\MongoDB Compass\resources\app.asar.unpacked\node_modules\native-machine-id\build\Release\native_machine_id.node
    at process.func [as dlopen] (node:electron/js2c/node_init:2:2617)
    at Module._extensions..node (node:internal/modules/cjs/loader:1980:18)

The loader IIFE in native-machine-id/dist/index.js re-throws when both Release and Debug binaries fail to load:

const binding = (() => {
    try {
        return require('../build/Release/native_machine_id.node');
    }
    catch (outerError) {
        try {
            return require('../build/Debug/native_machine_id.node');
        }
        catch {
            throw outerError;   // kills Compass startup as an unhandled rejection
        }
    }
})();

This throw happens during main-process startup before the main window and before logging are set up, and the resulting promise rejection is never caught, so startup dies with zero user-visible feedback. The rest of the module already degrades gracefully (getMachineIdFromBindingSync/Async both catch and return undefined).

Requested action (either fully resolves it):

1. Code-sign native_machine_id.node like the main executables, so Smart App Control / WDAC allows it.
2. Make the native-machine-id loader (and the telemetry getDeviceId call site) tolerate a failed native module load instead of throwing — telemetry machine-id resolution should never be able to abort application startup.

Also worth considering: a top-level unhandledRejection handler during main-process bootstrap that surfaces a dialog/log instead of dying silently — this failure was hard to diagnose because there was no window, no log file, and no event-log entry.

Steps to Reproduce

1. Windows 11 machine with Smart App Control enabled (HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy → VerifiedAndReputablePolicyState = 1), where SAC blocks the unsigned native_machine_id.node (reputation-based, machine-dependent).
2. Launch MongoDB Compass 1.49.12.

Expected Results

Compass opens; worst case telemetry machine-id resolves as "unknown". If a required component is blocked by OS policy, an error dialog or at least a log entry should appear.

Actual Results

No window, no Compass log file, no Windows event-log entry; orphaned MongoDBCompass.exe processes accumulate with each launch attempt.

Additional Notes

Verification of the diagnosis: patching the loader to return undefined; instead of throw outerError; (everything downstream already handles an undefined machine id) makes Compass start and run normally on the affected machine, with Smart App Control still enabled.