Crash: write to nullptr on main thread while typing in message field (7.0.1, Windows x64)

[iltempovola]

Summary

Telegram Desktop 7.0.1 (official Windows x64 installer build) crashes with a write to a null pointer on the main/UI thread while typing in the message compose field. Two crashes occurred within ~2.5 hours of a fresh install, both at the exact same code address, so this looks deterministic rather than memory corruption.

I analysed both minidumps in WinDbg/cdb. Since public PDBs aren't published, all addresses below are given as Telegram.exe RVAs so they can be symbolized against the official build.

Version / environment

• Telegram Desktop 7.0.1 (official installer, AppData\Roaming\Telegram Desktop, signature valid — Telegram FZ-LLC)
• Internal Launched version: 7000001, install beta: FALSE, alpha: 0, debug mode: FALSE
• Windows 11 (10.0.26200), x64, 8 logical CPUs
• GPU: Intel Arc 140V, renderer ANGLE (Intel, Intel(R) Arc(TM) 140V GPU (16GB) Direct3D11 vs_5_0 ps_5_0, D3D11-32.0.101.8724)
• OpenGL profile: OpenGLES, Renderer: [OpenGL] (Window)
• devicePixelRatio 1, screen scale 100

Exact build fingerprint (for symbolization)

Image name:  Telegram.exe
Timestamp:   Tue Jul 14 21:05:47 2026 (6A56342B)
CheckSum:    0CC0455B
ImageSize:   0DF14000
File version: 7.0.1.0

Exception

Identical in both crashes:

ExceptionCode:   c0000005 (Access violation)
NumberParameters: 2
  Parameter[0]: 0000000000000001   (write)
  Parameter[1]: 0000000000000000
Attempt to write to address 0000000000000000

Faulting instruction:  mov dword ptr [rax],ecx     with rax = 0
Faulting RVA:          Telegram.exe+0x401785
Thread:                main / UI thread

Register state at the fault was effectively the same in both dumps (rax=0, rcx=0, rdx=0, rsi=0, r15=0, r9=0x80).

Stacks (Telegram.exe RVAs)

The top three frames are byte-identical across both crashes:

Telegram.exe+0x401785     <-- faults here (write to nullptr)
Telegram.exe+0x1A12A05
Telegram.exe+0x1A12618

Crash A

00  Telegram.exe+0x401785
01  Telegram.exe+0x1A12A05
02  Telegram.exe+0x1A12618
03  Telegram.exe+0x55D84A4
04  Telegram.exe+0x55D6EA0
05  Telegram.exe+0x50B9363
06  Telegram.exe+0x375998A
07  Telegram.exe+0x50E1665
08  Telegram.exe+0x50E071C
09  Telegram.exe+0x116771B
10  Telegram.exe+0x55F0BAB
11  Telegram.exe+0x55F249F
12  Telegram.exe+0x58EA95E
13  Telegram.exe+0x5702DF1
14  Telegram.exe+0x58EA938
15  Telegram.exe+0x56207AD
16  Telegram.exe+0x55EFBE4
17  Telegram.exe+0x1163067
18  Telegram.exe+0x113845D
19  Telegram.exe+0x1135B9A
20  Telegram.exe+0x2AB06EE
21  Telegram.exe+0x5A607E7
22  Telegram.exe+0x59E0032
    kernel32!BaseThreadInitThunk+0x17
    ntdll!RtlUserThreadStart+0x2c

Crash B

Note frames 10–19 and 23–32 are an identical repeating block, i.e. the same dispatch path re-entered (nested event delivery) before the fault:

00  Telegram.exe+0x401785
01  Telegram.exe+0x1A12A05
02  Telegram.exe+0x1A12618
03  Telegram.exe+0x1A0EB4C
04  Telegram.exe+0x1A1815D
05  Telegram.exe+0x40E59B
06  Telegram.exe+0x4781C1
07  Telegram.exe+0x5E4FE2
08  Telegram.exe+0x9207F5
09  Telegram.exe+0x375C482
10  Telegram.exe+0x40E66C     <-- repeating block starts
11  Telegram.exe+0x40E4D7
12  Telegram.exe+0x40E2AB
13  Telegram.exe+0x3759BF7
14  Telegram.exe+0x50E1665
15  Telegram.exe+0x50E071C
16  Telegram.exe+0x116771B
17  Telegram.exe+0x55F0BAB
18  Telegram.exe+0x50C3FE3
19  Telegram.exe+0x50C38D3    <-- repeating block ends
20  Telegram.exe+0x1A17DCF
21  Telegram.exe+0x1ED60DD
22  Telegram.exe+0x375C0D6
23  Telegram.exe+0x40E66C     <-- same block again
24  Telegram.exe+0x40E4D7
25  Telegram.exe+0x40E2AB
26  Telegram.exe+0x3759BF7
27  Telegram.exe+0x50E1665
28  Telegram.exe+0x50E071C
29  Telegram.exe+0x116771B
30  Telegram.exe+0x55F0BAB
31  Telegram.exe+0x50C3FE3
32  Telegram.exe+0x50C38D3
33  Telegram.exe+0x1A110E8
34  Telegram.exe+0x189001A
35  Telegram.exe+0x1A78848
36  Telegram.exe+0x1A7D1AB
37  Telegram.exe+0x1ED60DD

Both stacks converge on the same tail: +0x3759BF7/+0x375998A -> +0x50E1665 -> +0x50E071C -> +0x116771B -> +0x55F0BAB.

Steps to reproduce

No deterministic repro yet. Both crashes happened during normal use while typing in the message field; no formatting features were being deliberately invoked. Crash A occurred ~1h20m into a session, crash B ~15m into the next session.

Notes that may help narrow it down

• The process is clean: no third-party DLLs injected (no AV hooks, no overlays). Only Windows system DLLs plus Telegram's own bundled modules\x64\d3d\d3dcompiler_47.dll.
• MsSpellCheckingFacility.dll is loaded (Windows spell-checking), but it has no frames on the crash stack.
• Suspicion is the new rich text editor introduced in the 6.9.4 beta / 7.0 line, given the crash occurs while typing and 6.9.3 already fixed editor-field issues ("possible crash in formula parsing", "fix field resize after Undo/Redo").
• The mov dword ptr [rax],ecx with rax=0 pattern suggests a struct/member write through a pointer that a caller assumed non-null.

Dumps

I have both minidumps. I'm not attaching them publicly because minidumps contain process memory that can include message content and potentially auth material. Happy to send them privately to a maintainer, or to run further specific WinDbg commands against them and post the (non-sensitive) output on request.