Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.microsoft.windows > #3410

Re: What do you use to read your Windows crash logs?

Cross-posted to 3 groups.

Show all headers | View raw

Hank Rogers wrote:
> What do you use

I've never analyzed crash logs, which is why I asked the question of
experts, since I am a team player who works together for all to benefit.

While I was waiting for an answer, I downloaded the Microsoft debugger.
C:\> winget download Microsoft.WinDbg --download-directory .
     Found WinDbg [Microsoft.WinDbg] Version 1.2603.20001.0
     This application is licensed to you by its owner.
     Microsoft is not responsible for, nor does it grant any licenses to,   
     third-party packages.
     Downloading     
https://windbg.download.prss.microsoft.com/dbazure/prod/1-2603-20001-0/windbg.msixbundle
       100%  771.0 MB /  771 MB
 Successfully verified installer hash

Since I don't know, offhand, how to handle that bundle, I installed it.

C:\> winget install Microsoft.WinDbg
     Found WinDbg [Microsoft.WinDbg] Version 1.2603.20001.0
     This application is licensed to you by its owner.
     Microsoft is not responsible for, nor does it grant any licenses to,
     third-party packages.
     Successfully verified installer hash
     Starting package install...
       100%
     Successfully installed

C:\> where windbgx
     C:\Users\username\AppData\Local\Microsoft\WindowsApps\WinDbgX.exe

Win+R > shell:AppsFolder > Rightclick on WinDgb > Create shortcut
TARGET Microsoft.WinDbg_8wekyb3d8bbwe!Microsoft.WinDbg

So now CrashDumps & WinDbgX are shortcuts in my taskbar pullout menu.
 taskbar:menu > hardware > crashlogs > {crashlogs,windbx}.lnk

C:\> WinDbgX
     (up pops the GUI)
     WinDbgX:File > Open > %LOCALAPPDATA%\CrashDumps\*aloha* 

Apparently, verbose WinDbgXanalysis digs through all the active threads at
the time the huge crashlog was created where it was no "mini dump" given
 "User Mini Dump File with Full Memory : 
  Only application data is available"

Even though it calls itself a "Mini Dump," it was captured with Full
Memory. That means Windows dumped the entire chunk of the 16GB RAM that
aloha.exe was actively using right when the Aloha browser crash died.
    "The stored exception information can be accessed via
   .ecxr(f4.1470): Access violation - code c0000005
    For analysis of this file, run !analyze -v
    <Unloaded_libalohasync.dll>+0x19dff0:
    00007ffa`4d20dff0 ??              ???"	

Access violation - code c0000005: This is the classic Windows error for a
memory panic. The program tried to read or write to a virtual memory
address that it didn't own or that didn't exist.

<Unloaded_libalohasync.dll>: This is the prime suspect. aloha.exe relies on
a background module called libalohasync.dll (likely responsible for cloud
syncing, local data syncing, or network communication).

The Problem: The module was unloaded from the system's RAM before the
program was finished using it. The main program tried to jump to address
00007ffa4d20dff0 to execute a sync instruction, but found a graveyard of
question marks (?? ???`) because the DLL was already gone.

To get the full story and see exactly which thread pulled the rug out 
from under the sync module, I ran "!analyze -v" as WinDbgX suggested.
 
!analyze -v

    Failure.ProblemClass.Primary  Value: SOFTWARE_NX_FAULT
    Parameter[0]: 0000000000000008
    Attempt to execute non-executable address 00007ffa4d20dff	0

The stack trace tells a very specific story of a bad architectural handoff
due to a programming bug in Aloha when it hands things off to Windows.

Step A: aloha.exe spun up a background worker thread using Microsoft's
standard library function: msvcrt!_threadstartex.

Step B: This background thread was tasked with running code inside
libalohasync.dll (likely a cloud/syncing feature).

Step C: While that worker thread was still actively running or waking up,
the main Aloha program decided it was done with the sync module. It
forcefully freed and unmapped libalohasync.dll from the system RAM
(IP_MODULE_UNLOADED).

Step D: The worker thread (_threadstartex) woke up, moved its instruction
pointer (rip) to address 00007ffa4d20dff0 where the sync code used to live,
and tried to execute the next line of code.

Because the DLL had already been ripped out of RAM, that address was no
longer a valid code block since it was just dead, unallocated space. The
CPU read the address, realized it was violating NX protection rules, threw
the c0000005 Access Violation and collapsed the program.

This is 100% a programming bug in the Aloha software itself, not an issue
with the Windows environment. The Aloha software developers, having never
once ever tested their own code sufficiently, apparently forgot to safely
stop and join their background sync threads before unloading that specific
libalohasync.dll from memory.

Since this is my first crash debug attempt, I am wondering what others on
this newsgroup use to debug crash logs found in %LOCALAPPDATA%\CrashDumps
-- 
The whole point of conversations on Usenet is to discuss topics of mutual 
interest among people who may know more than you do about that very topic.

Back to alt.comp.microsoft.windows | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: What do you use to read your Windows crash logs? Maria Sophia <mariasophia@comprehension.com> - 2026-05-29 19:18 -0600
  Re: What do you use to read your Windows crash logs? T <T@invalid.invalid> - 2026-05-29 19:28 -0700
  Re: What do you use to read your Windows crash logs? malxau <invalid@invalid.net> - 2026-05-30 04:39 +0000
    Re: What do you use to read your Windows crash logs? Maria Sophia <mariasophia@comprehension.com> - 2026-05-30 14:22 -0600

csiph-web