Repository navigation
Zoom SDK helper disappears during real meeting; exit cause missing from diagnostics #856
Description
The installed beta-2026-10-10-abb97fb (main abb97fb) lost its local Zoom helper during a real meeting at 2026-10-10 09:06:24 EDT.
Evidence:
- Helper ready at 09:05:34, authenticated at 09:05:36, joined at 09:05:47; raw media became active at 09:05:51.
- At 09:06:24.2879521, native log:
Zoom SDK helper connection lost. Rejoin the meeting to restore Zoom media. - Subsequent process inspection: WinUI PID 23092 and native core PID 47724 remain running continuously since 08:31; corevideo-zoom-engine.exe absent.
- Fresh control snapshot reports meetingState=error, Zoom joined=false; compositor remains live.
- No matching recent Application Error/WER event or new crash dump found. Full WER dumps are configured for the helper.
Assessment: unexpected local helper process/IPC loss confirmed. This is stronger than evidence of a network-only meeting disconnect, but a native exception/crash, termination, or orderly helper exit cannot yet be distinguished. Do not claim a fault module, exit code, network cause, or relationship to #790 without evidence.
Diagnostic gap: ZoomEngineRuntime::readerLoop reports readEvent failure as generic connection lost. ZoomEngineProcessClient::running reads but does not expose/log process exit code. Capture child exit status and IPC/parser failure reason on loss, preserve SDK status sequence and matching crash evidence, and reproduce safely to identify the causal path.
Done when: causal helper-exit path identified and fixed with regression validation; diagnostics distinguish helper death, IPC/protocol failure, and SDK meeting/network disconnect. Real-meeting acceptance remains required.
Local redacted evidence: artifacts/incident-20261010-090624 in beta-roi-2026-10-10 worktree. No session restart or app modification performed during diagnosis. Intake is unranked pending owner prioritization.
Activity
iamfatness commentedon Oct 11, 2026
October 11 recurrence; attribution materially improved after checking Zoom's own crash directory rather than only WER.
Installed beta abb97fb, WinUI PID20648 and native PID33016 remain alive continuously since October 10 11:01 EDT. Local helper PID55164 disappeared; fresh snapshot meetingState=error/joined=false, 15 participants retained, webcam still live. Native IPC loss logged at 2026-10-11 09:44:30.0855598 EDT. No restart or rejoin performed.
Zoom-managed crashrpt.xml timestamps the actual crash at 2026-10-11T13:44:20Z (09:44:20 EDT). Matching dump: ZoomSDK/logs/zoomcrash_094420_55164. SDK version 7.0.5.39292. cdb confirms exception c0000005, null WRITE at sdk.dll RVA 0xeff00, reached through ucrtbase raise/abort/terminate after a C++ throw in zoom_meeting_bridge.dll. The thrown exception object's message is "bad allocation" (verified in object memory and its constructor). Stack continues through the meeting bridge, mcm and nydus worker; no CoreVideo frame on the faulting stack. This establishes a native helper crash caused by an allocation exception/termination path inside the Zoom SDK, not merely network disconnect. It does not establish why allocation failed or exclude an integration-triggered condition.
The previously missing October 10 evidence is also present under ZoomSDK/logs/zoomcrash_090616_45260: actual crash 09:06:16 EDT, c0000005 null READ at zoom_meeting_bridge.dll RVA 0xb55d9, same mcm/nydus stack family. Today's bridge callsite is RVA 0xb55a6, nearby but not the same exception. The October 10 generic IPC loss followed at 09:06:24. Earlier no-WER/no-LocalDumps result was correct for those locations but insufficient: Zoom's internal crash handler retained the dumps elsewhere.
Post-crash memory observation (~09:50 EDT): system committed about 124.4 GiB of 127.7 GiB; process private sum about 28.9 GiB; paged pool ~4 GiB/nonpaged ~1.9 GiB; largest live CoreVideo native private memory ~0.93 GiB and GPU committed ~1.20 GiB. Very low commit headroom is an investigation lead, NOT a proven at-crash cause or attributed CoreVideo leak. No resource-exhaustion event found. Physical available RAM alone does not describe commit capacity.
Preserved private local evidence: artifacts/incident-20261011 in beta-roi-2026-10-10, including copied current SDK logs/dump, fresh snapshot, debugger stack/exception/type evidence and memory counters. Dumps/encrypted SDK logs not uploaded because they may contain credentials/media. Next: capture commit/ownership history at runtime, distinguish allocation pressure from bridge lifetime misuse, include Zoom-managed crash inventory in diagnostics, and capture helper exit/IPC failure details. Root trigger still open; recovery is not a fix.
iamfatness commentedon Oct 11, 2026
Follow-up memory accounting at October 11 10:14–10:16 EDT: CoreVideo shell/core/helper processes are now all absent, but system committed memory remains ~121.73 GiB of 127.69 GiB, available physical RAM ~9.53 GiB. Total visible process-private commit ~26.45 GiB; paged/nonpaged pools ~4.44/~2.02 GiB. The remaining large commit difference is not attributed. Closing CoreVideo did not remove it; no evidence establishes a CoreVideo private-memory leak as the cause. Biggest grouped process private commit: node ~2.96 GiB, ChatGPT ~2.84, vmmemWSL ~2.29, Discord ~1.77, claude ~1.65, Chrome ~1.37, WebView2 ~1.36. Grouped working sets are not additive physical ownership because shared pages can be counted repeatedly. Physical RAM use and system commit must remain distinct. Need shared/VM/kernel commit attribution before claiming root pressure cause.
iamfatness commentedon Oct 11, 2026
SDK crash and system commit investigation � 2026-10-11
Confirmed ownership
Elevated, read-only native Windows handle/section inspection attributes 84.69 GiB of committed pagefile-backed shared sections to ASUS ArmourySocketServer.exe PID 16772, version 0.1.20.22. It holds 280,828 distinct section objects. Object addresses were available and used to deduplicate; none were redacted. Two racing handles could not be duplicated on the first capture. These are SEC_COMMIT sections, not image-file mappings or reserved address space.
Executable: C:\Program Files (x86)\ASUS\ArmouryDevice\dll\ArmourySocketServer\ArmourySocketServer.exe. Authenticode signature valid, ASUSTeK COMPUTER INC. The process started October 1 and has remained running for about ten days. Its process-private commit is tiny, which hides the shared allocation in ordinary process RAM/private-memory lists.
SystemPerformanceInformation reports 87.17 GiB shared commit, 122.28 GiB current total commit, and 127.69 GiB commit limit after CoreVideo has closed. ASUS accounts for about 97% of shared commit. Its retained section count/capacity increased between consecutive captures, consistent with a section leak; the internal ASUS call site is not identified.
Evidence at incident time
Windows Resource-Exhaustion-Detector System Event 2004 at 09:43:17.696 EDT records:
The SDK crash report is timestamped 09:44:20 EDT; helper IPC loss followed at 09:44:30. Dump analysis identifies a failed allocation and a C++ exception with message "bad allocation" in zoom_meeting_bridge.dll, followed by terminate/abort and the SDK fatal handler's deliberate null write. This was an SDK process crash, not simply a lost meeting connection.
Conclusion and limits
System commit exhaustion is strongly supported as the trigger for this incident, with the ASUS shared-section leak the dominant identified consumer. This is substantially stronger than inference from a post-crash memory reading: Windows diagnosed exhaustion approximately one minute before the SDK failed allocation. The dump lacks exact system commit at the failing instruction, so the causal chain is not yet proven by a controlled intervention. It does not establish that the earlier October 10 null-read crash had the same cause or rule out SDK/integration defects.
Next validation
Restart the ASUS component in a controlled step, measure whether roughly 85 GiB of commit is released, and verify that retained section growth stops after an update/remediation. Then repeat the SDK soak with commit-headroom telemetry. No ASUS process was stopped, no service/configuration changed, and no CoreVideo restart performed in this investigation. Preserve SDK containment/recovery work: an allocation failure must not leave the operator without a clear failed/recovering state.
Raw dumps, process command lines, section names, and host event XML remain local/private. This report contains the relevant measurements only.
iamfatness commentedon Oct 11, 2026
Controlled intervention confirmed shared-commit ownership: after the operator stopped ArmourySocketServer.exe PID 16772, the process disappeared. System commit fell from 121.793 GiB to 36.915 GiB (84.878 GiB released), and shared commit fell from 87.112 GiB to 2.427 GiB (84.685 GiB released). Commit limit remains 127.691 GiB; physical RAM available is now 11.21 GiB. This independently verifies that the ASUS process held the measured ~84.69 GiB shared allocation. Current system commit is ~28.9% used, with ~90.78 GiB headroom. SDK crash causality remains strongly supported by the pre-crash Event 2004 and bad-allocation dump; a new SDK soak is still needed to confirm stability after remediation.
iamfatness commentedon Oct 11, 2026
Post-ASUS-remediation installed SDK soak � 2026-10-11
Installed beta: beta-2026-10-10-abb97fb (same build as the incident). Joined the previously authorized test meeting via the installed shell control API. The native core and the SDK helper came from the installed package. No synthetic SDK mode, no code change, no replacement helper during the test.
SDK continuity PASS: 30 minutes / 1,800 seconds, 181 observations at 10-second intervals. The original helper PID 34904 stayed alive, meeting stayed joined with 10 participants, and every observed snapshot remained current. No new Zoom SDK crash directory or Windows Resource-Exhaustion-Detector Event 2004 appeared during the run. Real video callbacks are evidenced by 913 video-range classifications across 8 participant IDs in the current session log; the build does not expose per-participant frame counts in sources[], so the initial sampler's zero Zoom frame sum is unsupported and has been corrected to unavailable in the verdict.
System commit ranged from 38.700 to 42.942 GiB against a 127.691 GiB limit. Minimum observed headroom was 84.749 GiB. Shared commit plateaued around 3.53�3.57 GiB after warm-up. ArmourySocketServer remained absent. SDK private commit was about 1.73 GiB at intermediate checks and 0.493 GiB at the final supplemental check. Program production advanced 108,001 frames during the exact measured window.
Separate output qualification remains open (#825/#517): program-buffer deltas over the exact 30-minute window were 5 underruns, 5 overflows, zero buffer deadline misses, zero GPU-not-ready events, and zero output sequence gaps. The first underrun was sampled near 1,791.6 seconds. Supplemental endpoint comparisons (~30.5 minutes) show 23 compositor render-deadline misses and 5 dropped frames, zero degraded frames; webcam publication advanced 109,825 frames with zero publication exceptions and zero additional pending-frame replacements. Display-unconsumed increased by 114,381; this is an internal observation without display presentation proof and must not be described as physical output drops.
This supports successful remediation of the environment's commit-exhaustion trigger on an unchanged installed SDK build. It does not close all SDK crash causes or the zero-miss work. No participant churn, screen-share changes, recording, external camera receiver, or physical display delivery were qualified. The test meeting has been left running for the owner.
Private samples, snapshots and verdict are stored locally under artifacts/incident-20261011/post-asus-sdk-soak; meeting credentials and raw dumps were not uploaded.
Apply reviewer corrections to RC batch 2 plans (#1040)