Desktop Client troubleshooting guide

This article provides support information for troubleshooting the FileHold Desktop Application (FDA). The FDA will run on supported Microsoft operating systems.

The following information can be found on this page:

Troubleshooting guidelines

  1. Does every Desktop Client user have this issue? If only one user or a few users have the issue, it may be something specific that is wrong with that user's PC.
  2. What Windows desktop operating system is used? Be sure to have the latest service pack installed.
  3. What .NET framework is installed on the end-users PC that is having the issue? Be sure to have the latest version installed.
  4. What times during the day do these occur?
  • Each user should keep a simple list of when it happens, what they are doing at the time it happens and include the time it happens with this list for each occurrence of the issue.
  • Sometimes a pattern can be established that helps with troubleshooting.
  • The time / event list kept by a user for a few hours or a day or two can be double checked against the user's Windows desktop operating system's Windows Event viewer and the FileHold Server event viewer by an IT administrator or help desk technician.
  1. What is the user doing when the problem occurs?
  • For example, Logging in, Check out a file, getting a copy of a file, viewing a file, or sending a file to FileHold.

Folder options on the user's PC

Please ensure that you have Folder options configured so that you can properly see the Folders mentioned in this article.

  1. Show hidden files should be enabled.
  2. Hide protected operating systems files should be unchecked.
Image
Folder Options

Windows event viewer support

The Desktop Client application makes use of the desktop operating systems' Windows Event viewer, while the FileHold Server application makes use of the Windows Event viewer on the server. Both event viewers should be carefully examined for clues.

FDA error and trace logs

The Trace.log log is only present if there are .NET framework errors occurring. The error.log is the FileHold Desktop Client error log file. If you are using FileHold 12 and above, then these log files are available in the FDA via Tools > Export. Send the trace and error log to FileHold support for analysis. If a log file is blank then no errors have been logged. Refer to Exporting Error and Trace Log in FDA for more information.

The error log files are normally stored in C:\Users\YOURUSERNAME\AppData\Roaming\FileHold\FDA. In addition, the options.dat file is located in this folder. This is where individual user preferences are located. Sometimes this file does not have the correct permissions for the Desktop Application to function normally.

The trace log file is stored in C:\Users\Public\Documents and the user must have read/write access to this location in order for the trace log file to be created or updated. In some cases when launching the FDA a prompt will come up advising that the file cannot be created. This indicates that the user doesn’t have permissions to create the file and will need to be fixed.

Common FDA Issues

1. How the FDA was installed

We recommend that the application be installed and tested by an IT administrator so that it is verified that it can both connect to the FileHold server and that normal operations (get a copy, check out, check in a file, add a new file, search for a file) are all possible.

Before installation it is a best practice to examine the properties of the FDA Installer and make sure there is not an UNBLOCK button. If this exists, this should be clicked so that the application is not automatically blocked. We always recommend shutting down ALL other applications and temporarily disabling antivirus before installing any type of application. Read the FDA antivirus Settings - Best Practices article.

Only install applications if you have permissions and Windows rights to do so.

We recommend that you always right click an installer file and select "Run as administrator".

Another common mistake is downloading a zip package and not unzipping the zip package when running the installer. This is not advisable at any time. Always unzip applications from their zip archives before installing and make sure you are not installing from a temp directory!

2. The user's PC has a .NET Framework that is out of date or malfunctioning

Read the system requirements to ensure the latest version of the .NET framework is running.

  • We recommend that customers reboot their desktop machines when a repair or update or new install is made of the .NET Framework.
  • You may see event viewer messages on the user's PC similar to this which indicates a .NET framework issue:

EventType clr20r3, P1 fda.exe, P2 9.0.0.0, P3 4c93d193, P4 system.windows.forms, P5 2.0.0.0, P6 461ef203, P7 16b7, P8 159, P9 system.componentmodel.win32, P10 NIL

3. Crashing when logging in or launching FileHold

Windows user permissions issues:

There are several folders related to user permissions on the Windows PC that may have been changed, corrupted, blocked, or no longer function correctly. If the Desktop Client crashes on launch or login, a user permissions issue with one or two directories that depend on which version of Windows you are using. One method of troubleshooting is to logon to Windows as an IT administrator and try to run the FDA. If it functions normally, such as get a copy, check out, check in, and search, then it is most likely a permissions issue for the user who is having problems. Customers report that by giving the EVERYONE group modify access to the folders, the issue is resolved. You may also need to give the specific Windows user account / Domain user account rights to these two folders.

For Windows 7 x64 bit, check permissions in the following directories: C:\Program Files (x86)\FileHold\FDA and C:\Users\YOURUSERNAME\AppData\Roaming\FileHold\FDA and C:\Program Files (x86)\FileHold\FDA

User.dat or view.dat file is corrupted or damaged:

If the Desktop Client crashes on launch or login, there may be an issue with the user.dat file. The user.dat file can be damaged by sudden power loss, an operating system level conflict with antivirus, etc. To fix this:

  1. Exit the FDA completely.
  2. Navigate to the user folder and move the user.dat file to the desktop.
  3. Navigate to the following directory: C:\Users\YOURUSERNAME\AppData\Roaming\FileHold\FDA\<GUID> where <GUID> is the user's GUID. A GUID is the user's unique ID number and will be unique for each user. If multiple people have logged on with the same Windows profile, to the same PC then you will see multiple GUID folders. You can probably figure out which folder is which by comparing date/time stamps of the user.dat files.
  4. Locate the user.dat and the view.dat file. Rename one of these files to userOLD.dat and viewOLD.dat.
  5. Launch the FDA.

Crashing upon launching FastFind settings in User Preferences:

  1. Exit out of the FDA completely.
  2. Look for the settings.xml file which on is typically in this location C:\Users\YOURUSERNAME\AppData\Roaming\FileHold\FDA\FastFind\settings.xml
  3. Remove this file.
  4. Launch the FDA. You can set FastFind settings for that user PC. 

Random crashing when "getting a copy", checking out a file, or viewing metadata:

An error in the event viewer for the Windows 7 PC that indicates this problem is. For example:

Event ID 33 – SideBySide – Activation context generation failed for "C:\Windows\system32\conhost.exe". Dependent Assembly Microsoft.Windows.SystemCompatible,processorArchitecture="x86",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.7600.16816" could not be found. Please use sxstrace.exe for detailed diagnosis.

To fix this:

  1. Exit out of the FDA completely.
  2. Find the view.dat file within this specific user's GUID folder on the PC. If multiple users are sharing the same PC, then there will be multiple folders - and you will need to find the correct file by looking for the date stamp on the view.dat file.'Then remove the view.dat file. It is located in the <Application Data>\FileHold\FDA\<GUID> folder.
  3. Launch the FDA to test.

4. Crashing upon adding, downloading, or checking out a file

If the Desktop Client crashes when you are trying to download a file, update a file, etc (Get a Copy, Check out, open in Viewer) then your FileHold Working Folder directory should be examined for permissions issues.

  • Investigate permissions issues for the FileHold Desktop Client > Working Folder. The working folder is set in the User Preferences. By default this is set to C:\Users\YOURUSERNAME\Documents\My FileHold Documents.
  • Change the specific Windows domain account that is logged in to have full control of this Working Folder.
  • Sometimes customers have their Working Folder set to a file server. There could be permissions issue on the file server to troubleshoot.
  • If the Local Working Folder is set locally or on the network, try moving the Working Folder to a local directory on the Windows PC where the FileHold Desktop Client is installed and running by performing the following steps:
    • Creating a new folder on a drive that is accessible to the user with the issue
    • Logging into the Desktop Client and going to File > Preferences and Settings > User Preferences and then changing the Working Folder location to the new folder.
    • Test FDA functionality.

5. Windows Desktop antivirus security suite related

antivirus software and security suite software focuses on file activity. Document management software is intrinsically related to file activity. This can cause a few different issues:

  • Slow file transfers, uploading or downloading files, from the document management server during Get a Copy, Check Out, Check in or Open File in Viewer operations.
  • Interrupted file transfers
  • The abrupt closing of FileHold Desktop Client while transferring a file
  • Your antivirus software may need to have exceptions set so that real time threat analysis or file scanning is not performed on the My FileHold Documents folder. The FDA.exe may also need to be set as an exception for real time threat analysis. Please refer to this detailed support page for best practices with Desktop Antivirus and security suite software.

6. Network related

  • Occasionally, there can be network issues between FileHold Desktop Client and FileHold Server. WiFi networks especially can be prone to occasional interruptions, but wired connections can also have this issue too.
  • If you suspect this to be the case, then the Desktop Client's error.log and trace.log generally contain network related issues being logged.
  • The FDA requires a stable network connection at all times since the Desktop Client functions only when there is a stable connection between the Desktop Client and the FileHold server.
  • Sometimes user's need to VPN into their network to access FileHold remotely. VPN connections can also cause network reliability issues. For example, sometimes an out of date VPN client can cause sporadic and strange issues.

Cannot install FDA on Terminal Server or Citrix Server

FileHold Desktop Application Installation can fail on Terminal Server or Citrix Server. The installation process keeps in an endless loop with the message shown in the screen capture as below.

Image
FileHold Desktop Application Installation on Terminal or Citrix servers

Cause:

This is known issue by Microsoft. This problem is caused by an incompatibility with the Microsoft Embedded MSI technology and the Windows Installer Coordinator.

Resolution:

Disable the "Install Viewer" checkbox in the installation wizard during the FDA installation process.

Or, you may follow Microsoft’s official instruction to edit Local Computer Registry, Local Computer Policy, or Domain Group Policy to disable Windows Installer RDS Compatibility. After the FDA installation, the Windows Installer Coordinator can be turned back on.

https://support.accessdata.com/hc/en-us/articles/203263539-Windows-Installer-Coordinator-hangs

FDA install log error messages

If you see any of the following messages in the FDA install log, they can be ignored:

Failed to grab execution mutex. System error 258.

Internal error for Brava Installation.

SECUREREPAIR: SecureRepair Failed. Error code: 524EC8305C8

Error setting paths CommonFiles64Folder: 1: 2727 2: CommonFiles64Folder

Installer is x86 so it cannot get this path.

Error setting paths ProgramFiles64Folder: 1: 2727 2: ProgramFiles64Folder"

Installer is x86 so it cannot get this path.

Invalid certificate errors in the FDA

If there is a certificate name error in the FDA, the user is now prompted to remedy the issue. A message, “We cannot verify the secure connection to your FileHold server. Contact your FileHold server administrator to correct this situation.” appears.

Two options are available:

  • Ignore this message one time (unsafe). The user will be logged in as normal for the current session.
  • Ignore this error now and in the future (very unsafe). The user will be logged in as normal and ignore certificate errors in the future.

An option in FHIT > FDA Configuration can be enabled to never ignore certificate name mismatch errors when creating FDA installation templates.

FIPS policy exception

If you have enabled a FIPS policy at your organization you may see an exception in your error log. This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

The FDA uses the MD5 has algorithm to verify if files in the working documents have been changed from the files stored on the server. If it is not possible to create an exception in your FIPS policy, you can add an exception to the FDA configuration in C:\Program Files (x86)\FileHold\FDA\FDA.exe.config.

<configuration>
   <runtime>
      <enforceFIPSPolicy enabled="false" />
   </runtime>
</configuration>

The <configuration> node will already exist and will contain many other settings. Do not change them.