Skip to main content

NTDLL.DLL crashing D3VME on 10.4.0.2 over Windows 2022

  • August 4, 2026
  • 3 replies
  • 99 views
Brian Cram
Forum|alt.badge.img+3

We had a D3 customer who did a Windows update which updated the version of NTDLL.DLL (that's Windows' .dll not D3's). After that his 10.4.0.2 VME crashed five times in one day. After some investigation we determined that there was some heap corruption going on in D3 that was not detected by the earlier version of the NTDLL.DLL (10.0.20348.5020) but was detected by the updated version (10.0.20348.5139). When this heap corruption was detected, NTDLL killed the D3 VME. The customer then rolled back the NTDLL.DLL version and the VME crashes have ceased. In this particular instance, the NTDLL.DLL was updated by Windows update (Microsoft release) KB5087545 from May 12th, 2026, but that will change from update to update.

We at Rocket are looking into this, but meanwhile please be aware. We have not had this reported by anyone else other than this one customer, but that doesn't guarantee that it wouldn't happen to anyone else. We suggest that you NOT apply any Windows updates that contain the updated NTDLL.DLL until we figure out what's causing the D3 heap corruption.

    3 replies

    Brian Cram
    Forum|alt.badge.img+3
    • Brian CramRocketeer
    • Author
    • Rocketeer
    • August 6, 2026

    Something I forgot to mention in my original post: If this is happening to you and you haven’t alerted us or opened a support case, PLEASE let us know so that we better understand the potential scope of this issue.

    Brian Cram
    Forum|alt.badge.img+3
    • Brian CramRocketeer
    • Author
    • Rocketeer
    • August 17, 2026

    Well, we’ve talked about this internally. The one site on which this happened is still has ntdll.dll 10.0.20348.5139 installed and has no further crashes. Other sites all over the place are running 10.4.0.2 on fully-updated Windows systems with no issues. We now believe that this was a coincidence/fluke that the crashes happened so close to the ntdll message in the logs. Please ignore this and go forward. Thanks, and sorry for my “hitting the panic button”.

    Brian Cram
    Forum|alt.badge.img+3
    • Brian CramRocketeer
    • Author
    • Rocketeer
    • August 19, 2026

    And a further update: the customer whose system was crashing found the issue. It was a problem with flashBASIC calling a subroutine like this: CALL @PROGRAMNAME(arg,arg,blah) where the variable PROGRAMNAME was too long. Somehow the variable got a bunch of mutivalues added to it before the call. This is a known issue in flashBASIC and not a bug. If you’re using this technique, please remember to keep your variable names less than 90 characters. 90 is not the actual limit, but I can’t remember the actual limit and I know 90 is safe.

    Still scrolling?
    Ask a question
    Terms & ConditionsAccessibility statement