Recurring access violation in Adobe AIR.dll at +0x7444ee on AIR 51.1.3.8 (NULL 16-bit write) — looking for help identifying the function

[dominicseo-nsuslab]

Hello AIR team,

We're seeing a recurring native access violation inside Adobe AIR.dll on AIR 51.1.3.8 (Windows x64, captive runtime) in our production desktop application. We have a full-memory minidump and have done basic analysis, but since public PDBs aren't available we can't tell which function is faulting. We'd really appreciate your help mapping the offset to a function name, and any insight into whether this is a known issue in the 51.x line.

What we're seeing

Our application is a captive AIR x64 desktop app running on Windows 11 (build 26100). The runtime is Adobe AIR.dll version 51.1.3.8 (the file has the Pre-release flag set). The faulting process had been running for about 23 seconds when it crashed, on the main thread (thread 0), with the runtime hosting roughly 234 threads at the time.

The exception itself is a write access violation to a NULL address:

ExceptionCode    : 0xC0000005 (Access violation)
Operation        : Write
WriteAddress     : 0x0000000000000000
Faulting RIP     : 00007ff8`9f1b44ee
Module           : Adobe AIR.dll
RVA inside DLL   : 0x7444ee
Nearest export   : FRETrace + 0x3e7e

We mention FRETrace + 0x3e7e only because it's the closest exported symbol — we're confident the crash isn't actually inside FRETrace, but we don't have the private PDB to resolve it any further.

The faulting instruction and nearby code

The crash happens on a 16-bit indexed write where both the base pointer and the index are zero:

Adobe_AIR + 0x7444ee:
    66 89 04 51       mov     word ptr [rcx+rdx*2], ax
                                     ;; rcx = 0, rdx = 0  -> writes to NULL

Surrounding code (a few instructions before and after the fault):

+0x7444d4:  mov     rcx, qword ptr [r14+38h]
+0x7444d8:  movsxd  rax, edx
+0x7444db:  add     rax, rax
+0x7444de:  mov     edx, dword ptr [rcx+rax*8+0Ch]
+0x7444e2:  mov     rcx, qword ptr [rcx+rax*8]    ;; rcx <- table[i] -> comes back NULL
+0x7444e6:  movzx   eax, word ptr [r13]           ;; load 16-bit source value
+0x7444eb:  add     r13, r12
+0x7444ee:  mov     word ptr [rcx+rdx*2], ax      ;; crash: write to NULL+0
+0x7444f2:  mov     rax, qword ptr [r14]
+0x7444f5:  movzx   ecx, word ptr [rax+2]
+0x7444fd:  add     r8d, esi
+0x744500:  idiv    eax, ecx
+0x744502:  mov     rax, qword ptr [r14+38h]

The pattern looks like an indexed write into a buffer that's reached via a pointer table — the table is loaded from [r14+0x38], the i-th entry's pointer field is dereferenced into rcx, and that pointer comes back NULL.

Register state at the fault:

rax = 0  rbx = 0x7ec  rcx = 0  rdx = 0  rsi = 1  rdi = 0
r8  = 1  r9  = 0x7ec  r10 = 0x7ff937437518   r11 = 0
r12 = 2  r13 = 0x28fb2d87e04  r14 = 0x28f96b1a158  r15 = 0x28fb741e580
rip = 0x7ff89f1b44ee   rsp = 0xd7d477b430   rbp = 0xd7d477b498

Call stack

The thread 0 stack at the time of the crash, with FRETrace-relative offsets shown where they exist:

Adobe_AIR + 0x7444ee   (FRETrace + 0x3e7e)   <-- crash site
Adobe_AIR + 0x744319   (FRETrace + 0x3ca9)
Adobe_AIR + 0x5f9755
Adobe_AIR + 0x744a44   (FRETrace + 0x5284)
Adobe_AIR + 0x5fa093
Adobe_AIR + 0x383c0d
Adobe_AIR + 0x380d4f
Adobe_AIR + 0x54bd7e
Adobe_AIR + 0x56c469
Adobe_AIR + 0xd640b
Adobe_AIR + 0xd559a
0x00000211`e1b18b5a    <-- JIT-compiled ActionScript code
0x00000211`e1b180ca    <-- JIT-compiled ActionScript code

The bottom two frames are not in any loaded module — they look like JIT-compiled AS3 bytecode (the address range matches what we usually see for the AVM2 JIT region). So the crash flow appears to be: AS3 code → AVM2 entry → several internal AIR runtime calls → fault.

Why we think it isn't a single AS3 bug

This isn't a one-user, one-code-path issue. We've observed the same fault signature reproduce across many different users, and on our side the AS3 code paths immediately preceding the crash vary quite a bit — sometimes a UI event handler is running, sometimes a server response handler, sometimes the user has just been idle on a screen and a periodic timer fired. We have one user who crashes reproducibly across multiple sessions, but each time the AS3 trigger differs.

The interval between "last activity on the AS3 side" and the abnormal process termination is consistently small — usually within a few milliseconds — which suggests the fault happens synchronously, at or just after returning to the AIR runtime from AS3.

Because of the variety of AS3 code paths involved and the small native call stack above the fault, our best guess is that this is something at the runtime level rather than in any one of our handlers — but we're not able to confirm that without knowing what the faulting function is.

What we'd love your help with

1. Function identification. Could you tell us which function in Adobe AIR.dll 51.1.3.8 contains the instruction at RVA 0x7444ee? Knowing whether this is in AVM2 string handling, Stage3D resource upload, glyph rasterization, or somewhere else would help us a lot in narrowing things down on our side.
2. Known issue in the 51.x line. Have you seen this signature before — a NULL-dereferenced indexed write of a 16-bit value, after a pointer-table lookup? If it's already fixed in a later 51.x or in 52.x, we'd like to know which build.
3. Workarounds. If there's a runtime-level workaround (a feature flag, a JIT mode, something we can do from the app side), we'd be grateful for the pointer.

We're happy to share the minidump privately if that helps. We can also provide loaded-module info, full per-thread stacks, and the raw debugger output for the exception context.

Thanks very much for any help you can give us. Happy to provide more detail on anything above.

[ajwfrost]

Hi

Thanks for all the details. We can investigate - but the quickest option is probably if we are able to share the mini dump file? An upload link for this is:
https://transfer.harman.com/requests/28nFDBYGK5PcQzFE1bdbNg

many thanks

[itlancer]

@ajwfrost
I don't know is it the same but I have very rare similar crashes with 64-bit AIR application.
I got such crash log using AIR 51.3.1.3 and Windows 10 (10.0.19045):

EXCEPTION_ACCESS_VIOLATION
AV: READ at 0x0000000000000000
ExceptionAddress: 0x00007FF967184A8C
Module: C:\MyApp\Adobe AIR\Versions\1.0\Adobe AIR.dll
Stack trace:
  #00 0x00007FF967184A8C Adobe AIR! FRETrace + 0xA24C
  #01 0x00007FF9671849E6 Adobe AIR! FRETrace + 0xA1A6
  #02 0x00007FF96701C5B3 Adobe AIR! <unknown>
  #03 0x00007FF966DA2F51 Adobe AIR! <unknown>
  #04 0x00007FF966F0152E Adobe AIR! <unknown>
  #05 0x00007FF966F00EEB Adobe AIR! <unknown>
  #06 0x00007FF966BED90D Adobe AIR! <unknown>
  #07 0x00007FF966BEC9CF Adobe AIR! <unknown>
  #08 0x00007FF966E68D6E Adobe AIR! <unknown>
  #09 0x00007FF96705AAE0 Adobe AIR! <unknown>
  #10 0x00007FF96705ABBD Adobe AIR! <unknown>
  #11 0x00007FF966F07147 Adobe AIR! <unknown>
  #12 0x00007FF98DEE1088 atlthunk! <unknown>
  #13 0x00007FF9AF42EF5C USER32! CallWindowProcW + 0x60C
  #14 0x00007FF9AF42E684 USER32! DispatchMessageW + 0x4A4
  #15 0x00007FF967006C09 Adobe AIR! <unknown>
  #16 0x00007FF966D266B4 Adobe AIR! <unknown>
  #17 0x00007FF966AF8B4B Adobe AIR! <unknown>
  #18 0x00007FF966B797A0 Adobe AIR! <unknown>
  #19 0x00007FF9AEC57374 KERNEL32! BaseThreadInitThunk + 0x14
  #20 0x00007FF9B0C9CC91 ntdll! RtlUserThreadStart + 0x21

[dominicseo-nsuslab]

Dear @ajwfrost

First of all, please accept my sincere apologies for the delay in my response. I unfortunately missed your previous message, and when I tried to access the link today, I found that it had already expired.

Would it be possible for you to generate and share a new upload link with me? I am truly sorry for the extra work this causes you. I will make sure to upload the mini dump file immediately as soon as I receive the new link.

Thank you so much for your patience and understanding.

Best regards,
@dominicseo-nsuslab

[ajwfrost]

No worries - I normally adjust the default end date to extend these, I guess I forgot to this time! please see below for an updated link..
https://transfer.harman.com/requests/5bO5G8Kh1pjVp3H5Nv7EpC

thanks

[ajwfrost]

FYI, from some initial investigations:

The crash log from @itlancer is a problem when initialising the audio engine. It's one of those things that shouldn't occur, i.e. we are initializing the audio client (a Windows COM thing) and it's saying it succeeded, otherwise we would have handled the failure. But then it looks like we're getting a null pointer back. So we can perhaps increase the checks here so that we do a null-check as well as checking the return result...

The original crash log from @dominicseo-nsuslab looks like it's in a different location.. although having said that, it looks like it's in a function called on a background thread for handling the microphone, yet you mention it's on the main app thread (and if there's JIT-compiled code in the call stack then it should definitely be the main thread). And actually it looks like we had two builds of 51.1.3.8 in our system, so it's possible it was instead in a call to setting a matrix in a Stage3D context.. although the actual function call here is pretty innocuous and I can't see how it would contain those instructions or cause any crash..

So we may need to look at the call stack and let the system give us a bit more detail. In the meantime we'll tighten up that error checking to try to eliminate the audio initialization issues..

thanks

[ajwfrost]

@dominicseo-nsuslab thanks for the crash dump. This is showing a problem in the audio reformatter, trying to split audio samples across channels .. following the logic, it's another one where this shouldn't really be possible! We can again add some additional null-checks to try to reduce the possibility of a null dereference but there may be some other underlying issue that's causing the failure which could mean there is then an error that crops up in a different place...