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.  Should that not be the case less stringent timing is required or less of the display needs to be manipulated. Or best yet you need to buy a better video card. 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.

    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...

    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.  This is a feature added for Microsoft Surface 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).  Basically what I'm saying is that it's conceivable your item file is OK but the machine you're running it on is woefully deficient (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 before diving into complicated DMDX timing considerations.  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. .

    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.

    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 a number of the display errors above, usually 10 of them, 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.

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.  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.

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.

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.