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

Display error at ms %d, tick %d in item %d, frame "%s"
%d ms of refused video flips occurred

    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 and so on.  The task manager is useful in these situations allowing you to identify processes taking up the most resources (be they CPU time or whatever).

There were more than %d display errors

    This message appears after a number of the two 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.

Preparation A %d ms, B %d ms

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

DQ adjusted by %d ticks to allow for sound

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

RTF control word <\%s> used in quoted text, not supported

    Your editor has a used an RTF control word (or character) that DMDX does not support (see Item Files. above).  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).

Comma Frame Separator cannot be used with Sound Frames

    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.
   
READ ERROR BRANCHING (type %d) TO ITEM %d

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

PIO Polling FIFO full at time %dms

    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

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 will use the desktop resolution by default.

   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.

DMDX Index.