Reports

You said: Ok. Thank you, but I didn't know that an assembly program could crash silently. Is there any way I could detect silent errors like this in the future?

Yep—on Windows a crashing console program can look “silent” because the window closes fast and you miss the error. It wasn’t silent, though: you hit an unhandled exception (0xC0000005 access violation) and the OS terminated the process.

Here are practical ways to catch this immediately next time:

Check the exit code
Run from an existing console (not by double-clicking):

yourprog.exe & echo Exit code: %ERRORLEVEL%

You’ll see 3221225477 (= 0xC0000005) for an access violation.

Run under a debugger (break on first-chance)

WinDbg: windbg -o -G yourprog.exe (breaks exactly at the faulting instruction).
Visual Studio: Debug → Start Debugging (or attach).
x64dbg also works well for MASM binaries.

Force a break so you can attach
At program start:

extrn  DebugBreak:proc
sub    rsp, 40
call   DebugBreak     ; debugger will break here if attached, or you can attach now
add    rsp, 40

See the crash in Event Viewer
Event Viewer → Windows Logs → Application → “Application Error” entry will show the exception code and fault address.
Install a handler to log before exit
In x64, classic SEH frames aren’t written by hand; instead use a Vectored Exception Handler:

Call AddVectoredExceptionHandler to register a callback that logs the exception code / RIP and maybe calls ExitProcess.
(This is simpler than authoring x64 SEH unwind info in MASM.)

Keep windows open when double-clicking
Wrap your exe in a .cmd you double-click:

@echo off
yourprog.exe
echo Exit code: %ERRORLEVEL%
pause

Avoid the bug class
Use real storage (in .data) instead of writing to address 0. If you want to test crashes, deliberately jmp into int 3 or ud2 (illegal instruction) so the debugger catches it clearly.

These habits—run from a console, watch %ERRORLEVEL%, and use a debugger with first-chance exceptions—will make “silent” faults obvious.

79763398