During a run this error can crop up, it results from someone pressing the Windows key or Alt-Tab or something forcing another application into the foreground.  It will definitely disrupt DMDX's gathering of RTs (although safe mode 3 can make DMDX repeat the item that was disrupted).  If you're using a keyboard for testing you want to either have a separate testing keyboard (Windows will happily let you plug more than one in) with the Windows key and the Alt key removed or glued or covered up (one lab in Tucson used to have a cardboard flap that only left the response keys open but could be flipped up when not testing) or use another input device.  Most labs in Tucson had custom input devices, some people use USB game pads, there's a whole section on it in the help.  If you have programs on the machine prone to popping up messages you want to nerf them, if not permanently then certainly during a run.

    DMDX is constantly polling the raster status functions to synchronize itself with the raster, some machines (notably some modern laptops) overheat (I suspect anyway, I have no way of actually testing this) and block DMDX (sometimes for a number of seconds) so it switches to relaxed polling of the raster status.  Some machines can't even handle that so DMDX switches to simulating the raster and this warning is thrown when that happens and you probably want to avoid using that machine for testing purposes if you really care about accurate tachistoscopic displays or super accurate RTs (or investigate using a freesync video mode).  Each subsequent time DMDX is run it reverts to relaxed polling of the raster so if a machine temporarily fell into simulated raster tracking it has a chance to redeem itself, if not and DMDX gets blocked again it once again switches simulating raster tracking so this error can occur in every run.

  Prior to me adding this warning in version 6.3.5.1 of DMDX it's possible that people weren't aware their machines were simulating the raster synchronization as DMDX only emits display errors into the output file when said errors have affected the display of a frame, my guess most machines that are prone to overheating are lapsing into simulated raster tracking when the display is inactive at the start of a run so the addition of this warning is about the only way they'd know about it beyond them using test mode 1 and seeing the message about simulated raster tracking because once DMDX is simulating the raster tracking it's not at all likely that a display error will ever get thrown again (something I overlooked when I first added relaxed raster tracking).

    DMDX is constantly creating and releasing textures when using the Direct3D renderer and when I originally created the Direct3D renderer I never implemented logic to handle the video drivers telling DMDX when it asked for textures to be released that the textures weren't released, or that something else was still using said textures because no machine I ever saw did so.  As I was tracking down another error I noticed this thinking perhaps that was explaining the weirdness (a previous display was spuriously being used for the feedback).  Turns out that wasn't the case so I didn't have to write a rather convoluted set of procedures to handle releasing textures at a later date and instead just went with warning people that they probably have a memory leak.

  If you get a lot of these in a run or DMDX bombs out with worse errors at a later date your best bet is to switch that machine to using the DirectDraw renderer with TimeDX's Change Renderer command.

    These errors are thrown when a keyword has been used in an inappropriate place as certain keywords can only be used in the parameters at the start of an item file (where they're referred to as parameters), or can only be used in the bodies of an item in it's frames after the item number (where they're usually referred to as switches although that term can sometimes just refer to the original legacy single character DM and DMTG switches) and some can be used at the beginning of an item (where they're usually referred to as CR indicators, or correct response indicators) and some can be used in both item bodies and the parameter line (the only one that can be used in all three places is the comment keyword <!>).  Consult the relevant keyword's help page to determine a given's keyword's correct usage.

  The misplaced keyword at beginning of item message can be followed by the following text if the keyword being used is the extended parameters keyword (<EXTENDEDPARAMETERS> or <EP>) on the assumption that the item file is otherwise well formed barring the presence of blank lines at the start of the item file:

DMDX requires parameters to begin on the very first line of an item file, perhaps you have blank lines before your parameters?

    This error is usually thrown when the item file you are trying to use is not an .RTF rich text file.  Open your file in Word or WordPad and save it as an RTF file.

    This is an internal error that DMDX throws when it detects that the number of display operations that should have occurred didn't (the two forms depending on whether the Direct3D renderer is in use or not), typically each frame is going to generate a single display operation.  You can get it with certain uses of <AbortDQPurge> and also <FeedbackDuration 1>.  If your displays look good you can probably ignore it (but I'd post to the DMDX list serve if you aren't using <adqp> and ask for guidance myself), if you're asking for 1 tick feedback you might want to think about some non-tachistoscopic duration (I only discovered it when I made a debug build warp mode diagnostic for generating the HTML version of the introduction that rips through an item file as rapidly as possible).

    When using later operating systems (basically anything after Windows 7) DMDX should be using the Direct3D renderer as the old renderer, DIrectDraw, is emulated on later operating systems and using it results in timing errors, worse, on older versions of DMDX every third frame of multi-frame items is not displayed.  If you are using DMDX's auto mode then it will automatically use the Direct3D renderer, if not you will be prompted to choose which renderer and if you are using a later OS it's strongly urged that you use Direct3D -- said strong urging either isn't sufficient or my language is too opaque because some people continue to choose to use the DirectDraw renderer so in DMDX 6.3.1.5 I upped the ante and made DMDX spew this warning in both the diagnostics and the data files indicating that people might want to rectify it...

or

    When using extended or Unicode characters in a resource file name (be it graphic, audio or video) and you're using DMDX version 6.1.2.12 or later (prior to that it wasn't possible at all) it is necessary to have DMDX's Unicode option active.  Here the file name was שלוםעולם however I didn't have the Unicode check box checked so DMDX was trying to open the file using code page references and that doesn't work resulting in mojibake for a name, not only will DMDX not be able to open the file, it won't be able to display the name correctly when it throws an error message trying to tell you it didn't work.  Once the Unicode option is active DMDX should succeed at opening file as it will be using UTF-8 to encode file names everywhere.  If however it is still unable to open that file name (because it's not found say) and you see the name rendered as extended characters you should upgrade your version of DMDX as since version 6.1.2.13 DMDX is able to display Unicode characters in the run dialog so you should be able to see the file name in the error message rendered properly.

    When not using auto mode for every video mode and color depth that DMDX can use it must find the timing values of that mode in the registry. If they are not in registry you must put them there with TimeDX using TimeDX's Video Mode selection and the Advanced Vertical Retrace Sync test.

Wait for input thread to die failed

or

Wait for sound thread to die failed

   It's safe to ignore thread failing to die messages. Some machines seem to take forever to kill off threads that were doing things that are part a job that was running. Alas I never get to see such machines so never get to fully investigate them but the work of running the item file and saving the data has already been done so they are of no consequence. If the thread was responsible for saving data or some such thing there would be cause for concern but no thread is so it's just a case of me religiously sticking error messages around everything that possibly could fail and you having a machine that for some reason takes forever to kill off threads.

could not open registry key <SOFTWARE\TimeDX\some_name> error code 2

    DMDX is unable to locate a registry key containing information it needs to run. In between versions of DMDX new registry keys are sometimes added for new functionality, as TimeDX usually creates these keys it is necessary to run TimeDX again and set the new feature up and thereby create the new registry key. Some of the keys and TimeDX test to run to date are:   

    When a frame cannot be moved into video memory by the time it should be this error occurs. More often than not this error is caused by using a fixed delay which requires an item to begin displaying at a certain time but DMDX is still gathering subject responses (see the timing notes) and usually if that's the case the error occurs in almost all the items of the same design or whenever a subject takes longer to respond.  The error occurs because the item ends and DMDX is still waiting for a response from the subject however the delay code has gone ahead and scheduled the next item to begin at your delay interval ticks from whenever the last display element was displayed.  So if the item file is waiting for an RT (or is still playing audio, hell, digital video playback probably does it too) the time for that first frame of the next item rolls around but DMDX is still waiting so there's a delay error.  Lax scheduling (selected with a negative delay value) waits till everything's done before scheduling the next item's display.  Should that not be the case less stringent timing is required or if you're running on really antiquated hardware less of the display needs to be manipulated. This error used to cause the halting of the job as the display sequence was incorrect, however with the 0.08 rebuild of vid_int() timing errors and such forth are handled with considerably greater aplomb, now the previous frame will have been displayed while this frame was moved into memory for an extra time of however many ticks this frame is late by and all succeeding frames will be rescheduled to allow this frame to be displayed for it's correct duration.

    Should you have a video card with enough memory to buffer the complete item and are still getting this display error you probably need to increase the time between the request and the commencement of the display with the <Delay> parameter -- being careful to make sure you don't wind up with a request scheduled display by specifying the value with a negative number.

    A third line can appear as part of this message:

    -- possibly caused by another process taking %d ticks

    Here a certain video error has been detected by the retrace synchronization code as the kernel pre-empted DMDX during the presentation of the item so the code that moves stuff into video memory may have been robbed of it's usual amount of time to move frames and hence it may not be solely the design of the item at fault -- it would still be a good idea to adjust the timing of the item file to avoid such conditions as DMDX can do nothing about other processes needing to be executed (they are usually part of the kernel and if DMDX pre-empts them the machine stops working).

    In addition another line can appear as part of this message:

    -- also raster tracking is relaxed...

or

    -- also raster tracking is relaxed (every %d ms)... 

or

    -- also raster tracking is relaxed and now simulated...

    The presence of this line indicates that DMDX is no longer hammering the functions that give it the raster status information and is instead taking a relaxed route to tracking the raster.  The alternative versions are emitted by version 6.1.5.4 and later of DMDX as here if the code that detects if DMDX is being blocked is triggered repeatedly it ramps up the time the retrace polling routine sleeps for between each poll up to 1/2 of the raster interval at which point it throws the towel in and switches to simulated raster tracking (read no raster tracking as in EZ mode).  This is a feature added for Microsoft Surface and HP Elite devices that appear to have some congenital deformity that royally screws up DMDX's attempts to track the raster (basically their 3D hardware shuts down after a few seconds and only periodically wakes up thereafter).  The person who originally reported the issue didn't care to stick out the full diagnostic process to get to the heart of the issue so it was never fully resolved, there remains the possibility that frames may not be displayed, specifically they noticed the first frame of the tachistoscopic acid test wasn't being displayed after I had put the relaxed retrace tracking code in that stopped the Surface Pro from locking up for minutes on end.  As far as I can tell the Surface devices are more of a glorified tablet rather than cut down laptop and you might want to test your item file on a different machine, you might also want to contact me or the DMDX list serve so I can examine the issue in greater detail.  The person with the original issue decided to just go with DMDX's EZ mode and forget about tracking the raster and just live with  the slight (<16ms) display to RT synchronization error as they weren't gathering data with that machine.  Note that on other machines relaxed raster tracking still works pretty well, on my machine for instance the tachistoscopic acid test is flawless and if DMDX is capable of running that script it's pretty much capable of running anything, even when my machine is sleeping for 8 milliseconds it's still detecting the raster several times a second which more than adequate.

    This variant of the display error is strongly indicative of using an early version of DMDX on a later operating system, specifically operating systems from Windows 8 and up require the Direct3D renderer otherwise they will produce reams of these 24 or 25 millisecond refused Flip() errors, worse they may actually not display some frames.  Here the routine responsible for flipping a DirectDraw surface onto the display has failed to return for eons as Windows is busily emulating DirectDraw and turning the requests into Direct3D ones.  Why the errors consistently come out to 24 or 25 milliseconds is complete mystery but I saw that error produced on all sorts of hardware.  Whether Windows 10 continues this behavior or indeed returns other times is uncertain, I certainly don't see it with version 1709 on my current machine.

    DirectX has refused to flip the video pages and DMDX has retried the flip a number of times. This error can occur on some machines when pressing the machine to it's limits by presenting long sequences of 1 tick frames, basically it means DMDX is eager to get a flip done and DirectX ain't ready for it and it can also occur on other machines that have crappy video cards. This error is printed if and only if the time spent trying to flip the video pages is longer than the time to the next retrace, if it occurs with regularity then it could be because the maximum blit set with TimeDX is too big or more likely it is simply because the sleep time has been set too large and that video chipset cannot accept a flip too close to the next retrace. The frame will have been presented late by the number of ticks equal to the refused time divided by the refresh rate rounded up.

    There is one thing you can do to try and remove the refused flips errors and this is to dicker with the the timing parameters for that video mode in TimeDX / Advanced / Vertical Retrace Sync Thread. Essentially what is happening is that DMDX needs to setup the flip for the next retrace to display the next frame, however the video card is complaining that it can't do it at that time. In my experience it can't do it for one of two reasons, either DMDX has waited too long to ask for the flip and because it's a wretched video card it can't accept commands to flip when it's within a few milliseconds of the next retrace (most video cards have no problem with this) or it can't accept the command because it's busy blitting data to a video buffer, but this is much less likely as DMDX in most instances has so many video pages that it's likely to have moved everything into video memory long before the frames are going to be needing flipping to be displayed.

    So the first thing is to reduce the Sleeping Time, this is the amount of time that DMDX spends doing other things besides tending to the vertical retrace before the next retrace, so the longer this value is the closer to the next retrace DMDX will ask for a flip. Be careful however, reducing this value means DMDX has less time for other tasks. The other thing you can do is reduce the maximum number of lines to blit at once, this will make DMDX do less blitting in a single chunk and therefore tie the video card up for less time at a time and therefore possibly reducing the chance of a refused blit, but this assumes that you have a video card with little memory or are using a video mode that uses an enormous amount of memory -- you can see how likely this is to be the cause of your problem by looking at the diagnostics DMDX displays, at the start of running an item file there will be a line displaying the number of video memory buffers using the requested video mode for that item file, if there are more buffers than you have frames in an item this is unlikely to be the cause of your trouble.

    A third line can appear as part of this message:

    -- possibly caused by another process taking %d ticks

    Here a certain video error has been detected by the retrace synchronization code as the kernel pre-empted DMDX during the presentation of the item so the code that flips the pages may look to have been refused simply because the Kernel was executing instead. If the time refused is consistently just greater than the timeout time minus the sleep time you could try lowering the sleep time -- you can't lower it too much as the sleep time is the time that blits get performed.

    Either of the above Display Errors can have one of the following three additional diagnostics following it if the vertical retrace code is being dispatched by the millisecond callback (not the default case in Pentiums and any other machines with High Performance counters):

    -- but more than likely due to msec callback being %d ms late
    -- exaggerated by msec callback being %d ms late
    -- due to msec callback being %d ms late

    Pretty much when you see one or more of these qualifiers some other process on the system blocked DMDX from displaying the frame.  Here you need to simplify the machine by eliminating needless tasks, turn off network messaging services, not be serving up resources to other machines and so on.  The task manager (control-shift-ESC) is useful in these situations allowing you to identify processes taking up the most resources (be they CPU time or whatever).  If you can tell your anti-virus software to only update out of normal testing hours it's a good idea and of course you don't want it to be doing regular scans of the machine when you're testing either.  Should none of that be of any use I found an interesting page on optimizing a Windows 10 machine for low latency audio and many of those recommendations apply to DMDX albeit at the risk of reducing the machine's general usability so you might want to try a few of them.  A local copy if it is preserved here:

    This message appears after 10 of the display errors above occur in one item indicating that more errors occurred in the most recent item's display than have been reported. This is due to the fact that in order to stop the printing of a diagnostic further snowballing timing errors only a fixed number of them are queued, once more than that number are generated in a given item the rest are thrown away. When the next item is read they are printed and the queue reset.

    These are not errors, these are the time taken to prepare the item. Time A is the time taken after the display of the previous item finishes (including it's feedback), usually, but by no means always, before the request for the next item is received. It includes the time taken to flush any recorded responses to disk (AZK and ZIL but not DTP response modes), the time taken after an <animate> frame to set all the video memory buffers back to the background color and the time taken to read any bitmaps and wave files from disk. It also includes the time taken to send monitoring messages to a remote machine over the network if they are being used. If a job has the continuous running option set or uses the <continue> switch (or the user presses the request immediately) then the <delay> parameter must allow for this time as well as the B preparation time. The <MediaLife> keyword can be used to reduce preparation A times.
    Preparation time B is the amount of time spent loading fonts and manipulating bitmaps and assembling the images in memory prior to their being displayed tachistoscopically. The <delay> parameter must always allow for this time (NOTE: <delay> is specified in ticks while these times are in milliseconds).

    Not actually an error so much as a re-organization. In order to play a sound in accordance with it's visual probe it must begin before the current display queue begins, so the display queue has been moved later in time (the default delay has been extended for this item). If you have <RequestScheduled> on you may want to re-do your timing allowing for the length of the wave file.  This error usually occurs because the item begins with an audio segment and DMDX's cautious nature figures there's a chance that'll go astray so it shifts the item by tick to make sure the audio thread has a chance to schedule the audio before it's actually needed.  The solution is to begin the item with a visual display, even if it's just a blank frame for a single tick. Or live with the warnings, it's what I do...

    Your editor has a used an RTF control word (or character) that DMDX does not support (see Item Files).  You need to check the Ignore Unknown RTF checkbox in DMDX's main dialog.  After that if your display in DMDX doesn't match what your editor displays you'll have to reformat your item file, often opening and saving the file in WordPad will rectify this.  If the display effect you want doesn't survive WordPad there's a good chance DMDX won't support it anyway (for instance blinking text won't ever be supported).

    The use of the comma frame separator with a sound frame has been banned due to the unexpected results it provides. For instance, / "text" , <wav> / results in "text" being lost as the sound frame never generates a visual display to merge with "text" and / "oldtext" / <wav> , "text" / will leave "old text" on the screen merged with "text". Neither of these results are what the user expects to happen so the comma being an intrinsically visual operator is no longer usable with sound frames as they are non-visual.

    The item file contains a branch to an item number that is not in the item file. The most common cause of this is forgetting that to get DMDX to branch to an item number before the current item the destination item number must be negative. If you are having trouble diagnosing branches then turn on the branching diagnostics with <brdiags>.

    When using the QPIO12 or QPIO12output16 devices the queue used to store input data may become full and thus some input signal may be detected late. This normally happens during particularly intensive conditions, say as DirectDraw is initialized at the start of an item or during particularly bad display errors. If you find this error message occurring during data gathering you might want to provide a third parameter to reserve more than the default 16 elements of buffering in the <id> keyword to reserve more queue elements, for example <id qpio12 10,1,48>. See Input.

DirectX reports no support for Page Flipping.
The video card in this machine is not adequate for DMDX's purposes

or

DirectX reports no support for Page Flipping.
While TimeDX allows certain use of this DMDX will not.

    When hardware acceleration for a graphics card is turned down DMDX can't use features it needs to use.  Go to Display Properties / Advanced / Troubleshoot and set the hardware acceleration slider to Full.  That or use the Direct3D renderer...

WARNING: Explicit frame duration (% or <%>) used in EZ or auto mode, use <%ms> instead

    While using EZ or auto mode you have specified a frame's duration in terms of an explicit number of ticks rather than a number of milliseconds with <msfd>.  Which was fine in the bad old days when you had to time video modes manually and explicitly knew what the length of a tick was however today with auto mode automatically determining what a tick's duration is it's open to error.  Granted the absolute vast majority of displays are going to be 60 Hz displays so you'll rarely come to grief with it in your lab but there are more and more displays out there operating at frequencies other than 60 Hz and if you were doing a remote testing task sooner or later you'd come across situations where you weren't getting the frame duration you were expecting.

Reset to full screen failed!
D3DERR_INVALIDCALL (8876086C)

    By and large old video modes aren't supported by the new Direct3D renderer that has to be used under Windows 8 and up.  A lot of the time this is because modern monitors are wide things and old video modes are not but even then I find a lot of resistance to the older modes for some reason.  Under almost all circumstances you're going to want use <vm desktop> or just remove your <vm> specification as current versions of DMDX when using auto mode will use the desktop resolution by default.  Assuming you're already using <vm desktop> we've seen this error thrown when people try and run DMDX remotely through Zoom or using RDP (remote desktop protocol) and that doesn't work, instead use Remote Testing if you need to run DMDX on a remote machine.  And there was one instance where none of the above was the case and there updating the display drivers fixed the problem -- but that's one machine out of tens of thousands so reeeally rare.

  The old DirectDraw variant of this error message is:

SetDisplayMode failed. Unknown Direct Draw Error. (80004001[16385])

    A request has been made for a display mode that the machine cannot handle while using the legacy DirectDraw renderer.  Either use <vm desktop> or use TImeDX's Select Video Mode command to find one that it can handle.  This sort of error usually occurs on Windows 10 machines that have been upgraded from earlier OSes and DMDX is using the Direct3D renderer instead of the DirectDraw one and the range of video modes is different, however I suppose it's also possible that the range of DirectDraw modes is similarly circumscribed by the fact that DirectDraw is emulated under win10 and the machine actually just has DIrect3D display modes to choose from.

   If you really do have to use the old video modes because you have bitmap graphics that you don't want displayed at a different scaling than they were in the past you can use TimeDX and find out what comparable video modes are now offered.  Note, you don't necessarily need to time them as one would have had to do in the past, you're just using TimeDX to probe what available modes there are using Direct3D on your machine.  That or you can scale your bitmaps independently of the screen resolution and just present them as a fixed fraction of the screen's dimensions with the bitmap multpliers and a bit of scriptfu.

DI CreatedDevice failed DIERR_DEVICENOTREG

    DirectInput is complaining that the input device it's trying to use isn't registered by Windows.  Often encountered with international installs of Windows (but certainly not limited to them) trying to use the local keyboard device (for instance clavier in French installs) this is possibly caused by you using an older version of DMDX on a newer operating system or it's something that Microsoft screwed up in Windows 10 and they're not going to fix it.  You can either download the latest version of DMDX and see if the not registered error goes away or fall back to the traditional solution for international keyboard issues and use #keyboard for an input device and forget about using local names for the keys and use their numbers instead.

Button name <%s> not found on input devices

    Here one of  two things is happening, either you've used the actual incorrect name for a key or you're trying to use an international keyboard and there's some special character in the name of the key that you're unable to get into your item file correctly.  If you need to check the names of the keys you can check TimeDX's input test or you can use test mode 10 to see what the names of the keys are as far as DMDX is concerned.  Or you can fall back on the bullet proof traditional solution for international keyboard issues and use #keyboard for an input device and forget about using local names for the keys and use their numbers instead.  If you don't want to use #nnn button number names you might need to turn the Unicode option on as special characters can blow DMDX's name comparisons out of the water and once the Unicode option is active everything is converted to UTF-8 internally and use of special characters should no longer present a problem.

VMR9 RenderFile setup failed
VFW_E_NOT_FOUND (80040216)
An object or name was not found.

or

Failed to OpenFile
VFW_E_NOT_FOUND (80040216)
An object or name was not found .

    When playing video files DMDX gets error codes from DirectShow and all it can do is report them, it has no idea what's busted which means the poor user is tasked with parsing nasty old error codes from the dawn of time (well, Windows anyway).  Here it wasn't able to open the file you've specified.  Either you need to get the name right or add an explicit file extension if it doesn't have one or provide the right path.

VMR9 RenderFile setup failed
VFW_E_UNSUPPORTED_STREAM (80040265)
Cannot play back the file: the format is not supported..

or

Failed to OpenFile
VFW_E_CANNOT_CONNECT (80040217)
No combination of intermediate filters could be found to make the connection.

    When playing video files your computer needs to have the right codecs installed.  While you could always get this error message in the past Windows 10 has a truly woeful collection of codecs installed by default.  See the TimeDX Digital Video test..

WARNING: freesync frame duration %d ms in frame "%s" is less than the minimum refresh interval %f ms

    When using the freesync video mode option it is perfectly possible to request a frame's duration to be less than the minimum retrace interval, this is the warning that indicates you have done so.  If you don't know what the minimum retrace interval is for your video mode use TimeDX's Refresh Rate test.

MISSING $

    When scrambling an item file dollar characters are used delimiters for fixed blocks that are not to be moved, they must occur in pairs and the scramble routines have found an odd number of them in your item file.

Missing default frame duration.

Without specifying a default frame duration with <DEFAULTFRAMEDURATION> the default frame duration will be zero ticks leading to decidedly unintuitive results

    When I put that warning in I thought it was pretty self explanatory, turns out not to be the case.  In DMDX every frame specifies the time the next frame should be displayed at and unless a frame contains a specific duration the default frame duration will be used and for historical (stupid) reasons this is zero ticks.  So for a decade or so DMDX has had this warning in it's syntax check if that default value of zero isn't overridden by any of the default frame duration keywords or one of the usual frame duration keywords on the parameter line.  Because that warning only pops up in the syntax check it is actually possible to run an item file that's missing a default frame duration however when I test it I can still see frames that have have no explicit frame duration which shouldn't be the case as frames with explicit zero frame durations are in fact not visible (I know I just tested it). Digging into the matter I see that frames with an explicit zero duration request also get a flag set to explicitly not display them whereas frames without the explicit zero duration that are instead getting a zero default frame duration still get into the display queue and because the display routines only display one frame at a time (unless they've been specifically merged together with the no erase switch or the comma frame delimiter) they must be displaying the frame with the zero default frame duration for a tick and then displaying the frame after it -- which would usually cause a display error but I'm not seeing any evidence of it so I'm guessing the scheduling code is issuing the requests to display both frames before the time the second frame's display is to be displayed but because we're using the Direct3D renderer and the GPU is capable of buffering at least three displays DMDX never learns about the error (part of the reason DMDX is structured the way it is is to not be in a position to have to issue two requests like that).  Unintuitive indeed.