Hello,

I run ProgDVB Professional 7.72 on two machines as a 24/7 IPTV + recording setup. Both crash regularly. I analysed the crash dumps and can give exact fault locations, faulting instructions, register state and call stacks. I hope this saves you time.

There are three distinct signatures, not one.

═══ ENVIRONMENT ═══
Both machines run two ProgDVB instances at once, playing HLS/IPTV sources over the internet, with timeshift enabled (MaxTimeShift=8) and continuous recording. Some source streams are unstable and disconnect often — this appears to matter, see TRIGGER CONDITIONS below.

═══ SIGNATURE 1 — LAVVideo.ax+0xF116D — access violation reading a freed input sample ═══

Two full dumps, byte-identical code path in both.
Faulting instruction, disassembled from the dump's own memory image:
This is the AVX2 memcpy fast path, i.e. memcpy(dst = RCX, src = RDX, len = R8):
The source pointer is the problem. In both dumps that address is absent from the dump's memory ranges entirely — the pages were decommitted, not merely heap-freed. The pointer is not NULL and looks like a plausible heap address, so this is a dangling pointer, not a missing NULL check. The length differs per crash, consistent with a compressed frame payload.

Call stack, identical in both dumps, innermost first:
I located the exact source line. LAV Filters is open source and this is CDecAvcodec::ParsePacket() in decoder/LAVVideo/decoders/avcodec.cpp:
The registers map onto it exactly: m_pFFBuffer = RCX (LAV's own buffer, valid), buffer = RDX (your IMediaSample data pointer, unmapped), buflen = R8.

m_bInputPadded is set at avcodec.cpp:582 as m_bInputPadded = (dwDecFlags & LAV_VIDEO_DEC_FLAG_LAVSPLITTER), and that flag is only set when the upstream filter is LAV Splitter. With ProgDVB upstream it is false, so LAV takes this defensive path: it allocates its own padded buffer and copies your sample data into it before touching anything else.

This means LAV Video is not doing anything wrong. That memcpy is the first read of the sample data. So the window is not "LAV held the pointer too long" — the sample's memory was already released before or during the Receive() call that delivered it.

At the moment of the crash, 102 of 103 threads were parked in ntdll waits — the releasing thread had already returned, which is what you would expect from a lifetime race rather than true simultaneous access.

Also note the pages are unmapped, not merely heap-freed. A CRT/heap free would normally leave the page readable and produce corrupt video rather than an AV. That points at a buffer allocated with VirtualAlloc and released with VirtualFree, or an allocator Decommit().

Suggested fix. Because the very first read of the sample faults, the problem is on the delivery side, not in the decoder. Worth checking in this order:

1. IMemAllocator::Decommit() must not release the buffer memory until every outstanding sample has been returned. If ProgDVB's allocator VirtualFrees or decommits its arena on Decommit without waiting for outstanding IMediaSample references, this is exactly the observed failure.
2. Ordering of flush/stop vs. streaming: ensure BeginFlush / EndFlush / Stop cannot run the teardown path concurrently with an in-flight Receive() on the streaming thread.
3. Do not deliver a sample whose allocator has already been decommitted — on a source disconnect the streaming thread may still have one sample in hand.
4. If buffers are recycled rather than freed, the same symptom appears when a buffer is recycled one sample too early.

This reproduces on two machines with different CPU vendors, different GPU vendors and different Windows versions, so it is not driver-specific.

═══ SIGNATURE 2 — ProgDvbEngine.DLL+0xE93D9 — most frequent (machine B) ═══
Seven occurrences in 90 days, always the identical offset:
Same offset every time = a single deterministic code path, not memory corruption.

I could not analyse this one: no crash dump is produced on that machine, and the address is inside the protected region of the DLL. RVA 0xE93D9 lies outside the raw .text range (0x1000-0xB7200) of the on-disk image, so it only exists after the runtime unpacks — static analysis returns nothing there. A dump would resolve it immediately, as it did for signature 1.

Question: what is the supported way to make ProgDVB write a crash dump? On machine A there is a C:\PDVB\_crashdumps\ folder with ProgDvbNet.exe.<pid>.dmp files (~78 MB), but machine B has no such folder and produces none. If creating the folder is enough, please say so and I will capture one and send it. Otherwise I can enable Windows WER LocalDumps.

Two of the seven coincided (within 1 second) with a recording ending; the other five happened while that instance was only playing, so it is not recording-specific.

═══ SIGNATURE 3 — ucrtbase.dll+0xA527E — fast-fail from GDI+ / System.Drawing ═══
Entirely in the managed UI layer, unrelated to decoding. Looks like an invalid parameter reaching a GDI+ call — a disposed or concurrently-used Graphics/Bitmap on the OSD/skin drawing path would produce this. Note R8 = 0x7FFFFFFFFFFFFFFC, which looks like a bad size/offset.

═══ TRIGGER CONDITIONS ═══

I analysed 128 recordings over 22 days on machine B by measuring actual written bitrate. Sources that disconnect frequently correlate strongly with both stalls and crashes:
"Stalled" means the recording file stays open for hours while almost no data is written — e.g. 725 minutes producing 359 MB (0.07 Mbps). The existing 15-second no-data watchdog does not catch this (see below), and from the UI a trickling stream looks identical to a working one.

Every disconnect triggers a stream teardown/rebuild, and every teardown is another chance to hit the race in signature 1. Normal reconnects recover in 3-4 seconds; a crash costs about two hours because nothing restarts the application.

═══ ON THE EXISTING STREAM WATCHDOG ═══

I want to be accurate here: ProgDVB already has this recovery, and it works. On machine A I see it fire and recover correctly:
Three times today, roughly every two hours, each time recovering in a few seconds.

The gap is that the trigger appears to be absence of data for 15 s, and the failure mode above is not an absence — it is a trickle. A source delivering 0.07 Mbps never stops sending for 15 seconds, so the timer keeps resetting while the picture is unusable and the recording grows at 1/100th of the expected rate. The watchdog is presence-based; the failure is rate-based.

Request: could the refresh trigger also consider throughput — e.g. "if the incoming bitrate stays below X% of the nominal rate for N seconds, refresh the channel"? That would close the remaining case.

Question: ProgTV.win.ini contains RefreshLevelNetwork=0, which I cannot find documented anywhere. What are the valid values and what does each level change? If a higher level already makes recovery more aggressive, I would like to try that before asking you for a code change.

One more small request: auto-restart after a crash, or at least resuming an interrupted recording. A crash currently costs about two hours of recording because nothing brings the application back.

═══ WHAT I RULED OUT ═══

• Disk space — all record/timeshift paths point to a volume with 3.3 TB free.
• Hardware acceleration — irrelevant to signature 1 by construction: the fault happens in the input copy, before any decoding, so the decode backend cannot matter.
• CPU starvation — one machine was CPU-limited by a power policy. Fixing it (1.6 GHz -> 3.2 GHz, ProgDVB CPU use 107% of a core -> 16%) removed stuttering but did not change the crash signatures.
• Memory pressure — 31 GB / 20 GB, both machines had over 12 GB free at crash time.
• Drivers — different OS versions, CPU vendors and GPU vendors produce the same signatures.

═══ WHAT I CAN PROVIDE ═══

• Three full crash dumps (~78 MB each) for signatures 1 and 3.
• Report.wer files for all eight crashes on machine B.
• A dump for signature 2 as soon as you tell me how to make ProgDVB produce one.

I am happy to test a debug build. Thank you for ProgDVB — it has run this setup for years, and the stall/crash behaviour is the only thing standing in the way.

Try change video Demux in ProgDVB Options->Playback. Also you can try video renderer.