d7 may not function properly (updating, with dCloud, and FTP functionality) when running behind a Sonicwall appliance.  

This is because d7 utilizes passive FTP for certain functionality which in most Sonicwalls is blocked by default as a setting (in older models it may be labeled FTP bounce attack protection or similar) and also in those and newer models port 21 may need to be opened up in the firewall as well.  I am just speculating on the latter, I don’t have any definitive advice beyond that.

d7 gives me a warning when I try to run it from a UNC path or network drive.  What’s the risk of proceeding?

d7 may not function as expected.  Here are some of the things you should NEVER do while running d7 from a UNC path/network drive, and why:

• Never run multiple instances of d7 from the same UNC path/network drive simultaneously on different PCs – d7 frequently writes data to config files in d7.exe’s own directory which alters d7’s behavior.  If one running instance of d7 writes certain data to the config, and a second simultaneous running instance of d7 in the same path reads that data, results could be unpredictable.
• Never use DataRestore/DataMigrate – these functions rely on restarting the computer and then immediately accessing config files in the root of the d7 directory, which will fail before networking services are started.  
• Never start an app as a system service, or with system access (that requires a brief service installation.)  The reason for this is that services configured to start under the local system account will not start when the executable is on a network drive (as the system account does not have network access permissions.)  This can leave temporary Windows services installed by d7 that do not need to be there!  This includes:
  • Never start d7 with system access
  • Never start 3rd party apps with system access
  • Never start d7 in service mode (or the included KillEmAll, for that matter.)
  • Never use a custom app that is configured to put d7 into service mode to wait (e.g. Rogue Killer)
  • Never run Combofix from inside of d7.
• Never run from a UNC path/network drive where you have no write permissions, see issue below.

Why does d7 warn me when running from write protected media?  What are the risks of proceeding?

d7 at times will write certain data to the directory where d7.exe is located, or it’s Config subdirectory.  This effects all configuration operations, changing the sort order of custom apps, etc. in addition to other functions.

Some of the things you should never do while running from write protected media are:

• Run d7 without all 3rd party applications installed and all additional components pre-downloaded.  At worst, d7 may not be able to automatically download and run a 3rd party app.
• Perform many repairs on the repairs page.  At worst, some parts of the repair will simply fail.
• DataMigrate/DataRestore – these write critical data to config files in the d7.exe directory during operation.  Not only could these functions fail, a worst case scenario is some screwed up user accounts being created (or none at all) and data not being restored but copied to an unpredictable location.

Crashes

Sometimes d7 does crash, so what do you need to know about them that affects you?

• On a crash, d7 doesn’t get the chance to remove it’s Shell Extensions.
  • Fix: Run d7 again from the same location, and shut it down properly.
  • For more info, see the known issue, Explorer Context Menu items remain after d7 is run
• If d7 was operating on the registry at the time, d7 may have left registry hives loaded that shouldn’t be.
  • Fix: Run d7 again from any location, and shut it down properly.
  • Alternate Fix: Run UnloadReg.exe from the d7Modules directory after closing d7.
  • Manual Fix:  Fire up regedit and manually unload all hives under HKLM starting with “guest_”

Explorer Context Menu items may remain after d7 is run.

As mentioned above in Crashes, d7 may leave behind the shell extensions when it does not shut down properly.

To remove the shell extensions, in most cases all you need to do is relaunch d7 and close it down properly by clicking the Close button.

If this doesn’t work, you can force a removal. Simply relaunch d7, click on the d7 menu > and click the “Remove ALL Extensions” button. This will remove all of your context menu items added by d7 immediately.

Manual removal may be accomplished (Vista+) by deleting the corresponding key names from the registry under HKCR AllFileSystemObjects Shell

Anti-Virus Software Detection

d7 v3.4.4 fixed issues with false positives by a variety of antivirus vendors, however it seems by version 4, some vendors are at it again, likely using aggressive heuristics to the end of jacking up their detection rates by flagging otherwise legitimate apps.

Currently at least AVG, Comodo, and ESET all flag parts of d7, however ESET has informed me they will resolve the problem with their next definition update. AVG and Comodo (while the versions on virustotal.com detect filehandler.exe) assure me that their latest engine/definitions do not detect it.

Symantec’s SONAR heuristics also detect d7.exe as unknown malware, I have submitted d7 to them as a false positive, but they gave me the run-around, told me it *wasn’t* detected in their tests (when I know very well it IS), and asked me to submit d7 as a sample “threat” instead of a false positive!

Regardless, it’s a good idea to disable anti-virus software before utilizing d7, in some cases. Vendors and detection descriptions vary, and some components of d7, such as filehandler.exe (used by Shell Extensions) may be detected. Never fear, filehandler.exe, or any other component of d7, is not a virus.

Additionally, several of the 3rd Party Tools such as a few from www.nirsoft.net will be detected by a large variety of vendors’ products. They are not viruses either.

If you are uncomfortable with this, then simply don’t use d7!

Non-English Windows Versions

When I started the d7 project, I never expected it to take off and have world wide usage, therefore some things I just didn’t plan for.

Some parts of d7 will not function properly on non-English versions of Windows. This is because certain key directories may not be named as their English counterparts, for example the Desktop directory “Desktop” (and a few others) may be named differently. Currently the operations affected by this issue are:  DataMigrate/DataRestore and all Offline Ops require the actual directory names.  This is because the offline functions (including functionality in DataMigrate/DataRestore) cannot rely on the host OS to possibly know what language the offline OS is.

If you have a list of default Windows / Program Files / user profile directories for non-English languages, feel free to email me! Thanks!

Minor Issues:

• Systems with non-standard font sizes will have display issues with some d7 labels, cutting off some text.
• Sometimes d7 detects errors in the event logs, but doesn’t show them in the internal event viewer or it detects phantom errors…
• In MalwareScan, Some files (fewer than before! w/v3.2) aren’t properly resolved from their registry value data to their actual locations, for functions such as File Properties, Delete, etc. This can occur for example with a registry value containing rundll in front of the actual file you are after.
• The broken shortcuts detection is prone to report false positives, such as disconnected mapped drives, network shortcuts, and occasionally a local file shortcut possibly with an odd parameter in the shortcut target path.
• Occasionally offline registry hives (if used) are not unloaded on d7 close, you will receive a warning with an option to unload the hive if this is the case.
• In some rare circumstances, the d7 System Tray icon doesn’t disappear when closing d7.