[BUG]: RPI v1.9.0 crashes silently on Windows 11

[archfrog]

What happened?

I have a long list of crashes by Raspberry Pi Imager in my Windows 11 Event log.

I use RPI a lot (like 5-10 times a day, sometimes) because I am testing some kiosk generator software that I have written, which needs a fresh Ubuntu Server installation for it to work.

I never see any actual crashes (may be caused by my registry settings as I am a software developer), but there are a whole bunch of them in my event log. By registry settings I refer to the feature that you can disable the Windows error popup dialogue altogether.

I expect that there are never any crashes in my event log. I guess the crash occurs after I close the app after having made a bootable media for Raspberry Pi 4B using Ubuntu Server 24.04.1 for ARM64, because I wouldn't notice except for the event viewer log entries.

I've added a sample event viewer log entry.

Please let me know if you need more information or logs from the program (if they exist, I couldn't find any in %APPDATA%).

Version

1.9.0

What host operating system were you using?

Windows

Host OS Version

Windows 11 23H2 build 22631.4541

Selected OS

Ubuntu Server 24.04.1 for ARM64

Which Raspberry Pi Device are you using?

Raspberry Pi 4B, 400, and Compute Modules 4, 4S

What kind of storage device are you using?

USB Pen Drive

OS Customisation

• Yes, I was using OS Customisation when the bug occurred.

Relevant log output

Faulting application name: rpi-imager.exe, version: 1.9.0.0, time stamp: 0x00000000
Faulting module name: ntdll.dll, version: 10.0.22621.4391, time stamp: 0x7b2ab261
Exception code: 0xc0000374
Fault offset: 0x000000000010caf9
Faulting process id: 0x0x686C
Faulting application start time: 0x0x1DB3C206480DE51
Faulting application path: C:\Program Files (x86)\Raspberry Pi Imager\rpi-imager.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: bb91b4f1-00e3-4823-81d2-f3d78f4a03a7
Faulting package full name: 
Faulting package-relative application ID:

[tdewey-rpi]

Excellent report, thanks @archfrog.

This is exactly the reason we've not updated the website to point to 1.9.0 yet - because 1.9.0 includes a system-level change to favour host-OS cryptography on each platform. On Windows, this means we now use CryptoNG.

FWIW, I've not seen this in testing local Windows builds - certainly no error dialogs, that is - but possible some event log entries that I've not spotted yet. Thanks for the pointer.

[tdewey-rpi]

I've found a few issues in my CNG implementation, all of which come back to an assumption I made that we would calculate one hash by measurement, and compare that to the recorded hash in the Imager manifest.

Tracing with Microsoft debug tools reveals that we're seemingly creating 3 hashes simultaneously, and later filling them with data:

• An Image Hash
• A written bytes hash
• A verification measured hash

Further, rather than creating and immediately storing result in another variable - as I assumed such a design would work - we instead treat the hash object as state-carrying and call result() from multiple places.

As a result of the lifecycle assumptions I made, this now requires a much larger change than initially suspected.

[lurch]

🥚 ➡️ 🐛 ➡️ 🦋 ➡️ 🥚 🔁