Please see d7x Server Connectivity for issues in activating d7x, using the Config Mgmt Portal, or the d7xRDT.

Please keep in mind:

1.  Please try d7x again, it may not have “failed” to perform the task, but only failed to “re-launch” itself after the task, or failed to “stay active” and visible during a task or when running custom app (especially if the custom apps might interfere with d7x’s operation.)

2.  Ensure the d7x process has terminated before starting d7x again.  d7x will attempt to pick up wherever it left off after a crash, so if it was in “Auto Mode” it will pick up with the next item in the list after restarting.   You can also reboot the PC (if necessary) and d7x will still attempt to pick up wherever it left off.

3.  You cannot run multiple copies of d7x at the same time.  Launching any new instance of d7x will terminate itself if an existing one is found.  The only exception is when d7x relaunches multiple copies of itself for other various purposes, however you cannot launch multiple copies for normal use.

If you are running a newer version of d7x in order to fix an issue, you must delete the older d7x .exe file(s) before running the new d7x.  If this fails, then you have another older affected copy of d7x running, having been launched by the new d7x when it reads session data from the registry.  In this event you should close d7x and delete the registry value “AppEXE” located in:  HKLM\Software\d7xTech\d7x\Session\Paths and do the same for the \Session\Paths located in HKLM\Software\Foolish IT\d7x  and \d7II (if either exist) and then restart the new d7x.  This should be done prior to performing any steps below, only if the issue persists.

d7x can fail to start or in other tasks when run from your own PC, or a “TBC” aka “Tech Bench Computer” even though it does NOT fail at those tasks on a customer’s PC.

This can be an issue if your own PC is frequently used for d7x downloading/updating and configuring, especially when multiple copies of d7x are located and used from multiple locations on that PC, and the operator ignores the Session concept when switching between them (this can ultimately cause a lot of configuration headache, especially with the d7x Remote Deployment Tool.)  d7x always uses the Config and other resource folders that it was using when a session was first started on that PC, even from a different copy of d7x in a different folder.

1.  If d7x isn’t starting or performing, first try deleting the registry key:  HKLM\Software\d7xTech\d7x as well as HKLM\Software\Foolish IT\d7x and \d7II (if either exist.)

This key stores configuration and location information for the d7x files and paths that will be used by a running instance of d7x, and deleting it will remove all session data from that PC (of course this is normally done as part of the End Session tasks.)

Note this will not always be the only source for session data as d7x<->d7II compatibility is phased out with the introduction of newer features.

 2.  If d7x still won’t behave, then open the .\d7x Resources\Config dir where you are running d7x from, and ensure your computer name is not listed in the TechPCs.txt file (if it exists) and if so then remove it/save/retry with d7x.

Computer names stored in the TechPCs.txt file inform d7x to bypass certain startup tasks on those PCs (including any session start tasks, startup apps, or startup kill tasks.)

Note that you should always follow step 1 first (deleting the registry key for session data) since it could be pointing to a different \Config dir than you think you are working with.  This is because d7x will use the \Config directory it was using when a session is started on that PC, even if it was started by a different copy of d7x from a different folder.