60.1 Background Processing and Autostart
60.1.1 Architecture ¶
The actual processing is done by a dedicated background process (AXPProcessor) that the main program starts and supervises. This has two practical consequences:
- The user interface stays responsive even during large processing runs.
- The main window does not have to be visible - minimized or moved to the notification area, processing continues normally.
A watchdog supervises the background process and restarts it if necessary. If processing shows no sign of life for an unusually long time, the program reports a malfunction.
For operation without a logged-in user (servers, continuous operation), processing can instead be handled by a Windows service - see section 60.1.4.
60.1.2 When is processing active? ¶
| State |
Processing |
| Main window visible, minimized, or in the notification area |
Runs (at the configured check interval, see chapter 40.6.2) |
| Program closed via Exit |
Stopped - on the next start, new files in the monitored folders are picked up |
| Outside the time window (see chapter 40.6.3) |
Paused until the next window |
Recommendation for continuous operation: In the program options, enable Start program with Windows as well as Move to the notification area on startup/close (see chapter 40.5.3) - processing then runs unobtrusively all the time.
60.1.3 Behavior after pauses ¶
After a restart, computer standby, or the end of a time window, the program automatically processes files that arrived in the monitored folders in the meantime - files are not lost due to pauses. Only the pre-existing contents of a newly added folder are deliberately not processed automatically (see chapter 8.8.4); use catch-up processing for that (see chapter 60.2).
60.1.4 Running as a Windows service (external processor) ¶
For servers and continuous operation without a logged-in user, processing can be handled by a Windows service. This uses the program AXPProcessor.exe in the installation folder with the --service parameter; the main window is then only opened for configuration and to check the logs - in this mode, minimizing and closing do not go to the notification area (see chapter 40.5.3).
Important - same user account: set up the service with the user account you also use to configure the main program (in the service management console under "Log on as"; not "Local System"). Settings, profiles, logs, and the status display are tied to the user account - if the main window and the service run under different accounts, they cannot see each other.
Setup in the program (recommended): open Options → Windows service and click Set up service... - after you enter the service name, user account, and password, the program creates the service with a single administrator confirmation, including automatic startup (delayed), recovery after a crash, and the "Log on as a service" right (see chapter 40.7).
Manual setup (command prompt as administrator; adjust path and account - sc.exe requires a space after binPath=, obj=, and password=):
sc.exe create "AXP2Service" binPath= "\"C:\Program Files\Automatic X-Invoice Processor 2\AXPProcessor.exe\" --service"
sc.exe config "AXP2Service" obj= ".\YourAccount" password= "YourPassword"
Then enable the option Background processor is managed externally (e.g. as a Windows service) under Options → Windows service (see chapter 40.7). The same page shows the live status of the service and offers to start it right away and set it to start automatically (delayed) - including automatic recovery after a service crash; a single administrator confirmation is all it takes. If a manually created service points to the wrong program file, the page reports this and puts it right via Correct. In addition, the program itself checks whether the service is running when the options are saved and shortly after every program start (see chapter 40.7.2).
Two processes are normal: in service operation, two AXPProcessor.exe processes run by design - a supervisor (the actual service) and a worker process that performs the processing. If a file gets permanently stuck (see chapter 40.6.2), only the worker process is replaced and processing continues without intervention; the affected file is logged as an error.
Only one processor at a time: To make sure no file is processed twice, these locks apply:
- While a processing service is running, no program window processes as well - not in another session, not under another user (for example on a terminal server), and not without the option "Background processor is managed externally" being set. A program window without the option then shows "Processing by the Windows service" in the status bar.
- Without a service, only one program window processes per Windows user; a second session of the same user shows "Processing in another session of this user".
- Likewise, only one service or headless processor processes on a computer at a time: a second one, for example another service under a different user account, waits and only takes over when the first one ends. This also applies when the service is restarted while the previous service process is still shutting down.
Network drives in the service: A Windows service does not see the network drives a user has connected with drive letters. The program window therefore records at startup and regularly afterwards which network path is behind each connected drive letter. The service substitutes the recorded network path for paths such as Y:\Invoices - for monitored folders and storage locations as well as for lookup tables, recipient lists, or the centrally managed profile file. This only works if the drive is connected under the service account on this computer and the program window has run there. After importing profiles from another computer, this is often not the case. You then have two options: enter the network path (\\Server\Share\...) in the profiles instead of the drive letter, or connect the drive under the service account (with "Reconnect at sign-in") and start the program window there once. If a profile path is on a drive the service cannot resolve, the program points this out when the profile is saved or imported; in the log, the error message of the task names the reason.
Diagnostics: startup messages and operational events are written to the file ServiceDiagnostics.log in the application data folder of the service account (%AppData%\Automatic X-Invoice Processor 2\). At startup, the service logs there:
- the version, operating mode and data folder - with the marker "(NETZWERKPFAD!)" (network path) if the data folder is located on a network share,
- the line
Profil-Umgebung (profile environment) with the user, profile path, session and detected FSLogix or UPD profile containers,
- a warning if it runs as "Local System".
After a crash, the complete error trace is written there. The regular processing and error logs appear in the main window as usual.
Recommended - malfunction notification: for unattended operation, enable the malfunction notification (Options → Processing, see chapter 40.6.6) - the supervisor process then sends an email as soon as processing stalls for longer than the configured time span; the message additionally appears in the error log and the Windows Event Viewer.
Alternative without a service: AXPProcessor.exe --headless runs processing as a standalone console process (e.g. via the Windows Task Scheduler). Further parameters: --profile "Name" restricts processing to individual profiles (can be specified multiple times), --quit stops running instances. For the processing locks, a headless processor counts as a service (see above). --errorreport creates and sends the error report without processing (see chapter 80.2.4).
60.1.5 Terminal servers and user profile containers ¶
On a terminal server without a Windows service, the program processes the profiles of the Windows user signed in to each session; every user has their own profiles, options, and logs. Two sessions of the same user do not process at the same time. If a processing service runs on the server, only the service processes - with the profiles of its service account (see 60.1.4).
If user profiles are provided as containers (FSLogix Profile Container or user profile disks/UPD of the Remote Desktop Services), this does not readily go together with a service running under a user account:
- A Windows service running under a user account keeps that account's profile loaded permanently; the profile container stays locked as long as the service is running.
- If someone then signs in interactively with the same account, the container cannot be attached - Windows creates a temporary profile (User Profile Service events 1511/1515), and personal settings seem to have "disappeared".
Recommendations for such environments:
- Use a dedicated service account for the service and exclude this account from profile management in the FSLogix or UPD configuration (classic local profile). FSLogix provides the "FSLogix Profile Exclude List" group for this.
- Do not work interactively with the service account on a permanent basis - only sign in briefly for setup and profile changes.
- Whether the service runs in a container environment is shown by the line
Profil-Umgebung (profile environment) in the file ServiceDiagnostics.log (see 60.1.4).