There are various recovery actions you can and should take to reinstate system operation after a catastrophic or other failure which has triggered OMACHECK.  Precisely what actions are appropriate will depend on:

the type of failure

whether OMACHECK and a failed application are running on the same or different nodes

whether or not the program is still running which caused the recovery to be initiated.

This topic offers some guidance on how to decide what actions are possible and how to restart any failed applications and services.  Recovery actions generally involve a Windows command file (batch file), which should also be used to notify or log the action.

Restarting a Running COPIAFACTS Instance

It is often sufficient to restart COPIAFACTS to recover normal operations.  Where a system service such as BladeWare is involved, COPIAFACTS defaults to restarting the service when it is restarted.

If COPIAFACTS is still running normally, it can be restarted by executing the CFRESTART program.  CFRESTART drops a file named nodename.RESTART into the FAXFACTS folder and this causes the specified node to terminate and restart, after which the .RESTART file is deleted.  Because this action is file-based, it can be done from any node that can see the FAXFACTS folder.

To detect whether COPIAFACTS has been restarted, you should wait for a couple of minutes and then look for the .CFRESTART file in the FAXFACTS folder.  If the file is still present, you know that COPIAFACTS has not detected it (either because it was not running, or not seeing the file), and so has not been restarted.  The only options then are either:

to reboot the machine

to forcibly kill the application and then start it afresh.

An example batch file which will reboot if it cannot restart a CopiaFacts instance (running on the same machine) is:






Note that the .RESTART file incorporates a CopiaFacts nodename in its name, whereas the NTREBOOT utility needs the Windows machine name.

Killing and Restarting a COPIAFACTS Instance

The KILLFF utility can be used to cleanly shut down a COPIAFACTS instance running on the same mode.  It requires a nodename and an optional delay parameter which will force termination if a normal shutdown has not been successful.


You can also use the Windows TASKKILL command to terminate COPIAFACTS.EXE.  This will terminate the process forcibly, abandoning any transmission or reception operations in progress.  For details of the TASKKILL syntax, see  Note that with suitable permissions, you can use this method to terminate processes on another node.

After COPIAFACTS has been shut down, you can start it again on the current node by invoking COPIAFACTS.EXE with the Windows START command:


To restart COPIAFACTS on another node, it is simplest to start it originally in a command file which re-invokes itself after COPIAFACTS ends.  However this method has the disadvantage that it is tricky to actually shut down the program when necessary.  We recommend rebooting the node and configuring STARTCOPIA to ensure that COPIAFACTS starts up on reboot.

Killing and Restarting an FFEXTERN Instance

We do not recommend attempting to re-start a broken Document Converter instance: it is safer to re-boot the node in this case.  The reason is that when one of the FFEXTERN error timers has fired, it is often caused by one or more instances of Word, Excel, or an Adobe product which are still running and blocking further conversions, or by a problem with the Windows spooler service.  Just restarting FFEXTERN will not recover this situation.

Rebooting a Machine node

The NTREBOOT utility can be used to reboot the node on which it is run or another node on the network.  You will need to ensure that you have suitable Windows privileges to initiate a reboot.

The Windows SHUTDOWN command can be used in a similar way to reboot the same or another machine.  See

Finally, OMACHECK can automatically reboot a selected node when it is triggered.  This avoids the need to create a special command file if you always intend to reboot the node.  Because OMACHECK works with CopiaFacts nodenames, you must supply it (by right-clicking the name) with a machine name for each node you wish to reboot when the corresponding item is triggered.

You should normally have arranged for automatic startup of your CopiaFacts applications on starting Windows.  This is done with the STARTCOPIA utility.


A sample command file is provided for you to modify to match your requirements. This file will need to be customized before you specify it in OMACHECK to be run, and you will not need all of the included examples. This specific file is only suitable for use when you run OMACHECK on the same machine that is running COPIAFACTS.

EXIT  Remove this command when you have customized the file

REM When called from OMACHECK, parameter 1 will be machine name

REM When called from OMACHECK, parameter 2 will be Copia nodename

REM Program Files\Copia (or 'x86', in 64-bit) is assumed to be on the PATH


cd \copia\faxfacts

date /t >>omalog.txt

time /t >>omalog.txt

echo node=%1 machine=%2 >>omalog.txt

REM Write FS file to tell an administrator that OMA has triggered

EMTO.EXE subject="OMA triggered for %1 %2"

REM Attempt controlled, then forced shutdown of CopiaFacts (method 1)

echo "Calling KILLFF %1 60" >>omalog.txt

KILLFF %1 120

REM Forcibly shut down CopiaFacts (method 2)

echo "Calling TASKKILL /IM COPIAFACTS.EXE" >>omalog.txt


REM Start CopiaFacts again on this machine




REM Reboot a specific machine (method 1)

echo "Calling NTREBOOT %1" >>omalog.txt


REM Reboot a specific machine (method 2)

echo "Calling SHUTDOWN -r -f -m %1" >>omalog.txt

SHUTDOWN -r -f -m %1

This command file assumes that all the CopiaFacts applications reside in a folder on the PATH.  Please ensure that you have no executable files (perhaps old versions) in the COPIA\FAXFACTS folder.