Each log line follows this format:
2026-03-20 09:26:07.7229|INFO|[6]|ContextName| Message
Each process writes to a current log file (e.g. CaptureBackend.log) and rolls older sessions to numbered files (CaptureBackend00.log, CaptureBackend01.log, etc.). The numbered files are older — 00 is the most recently rolled, 09 is the oldest.
To find the session you care about, search across all files for the startup line and match it to the timestamp of the reported issue:
* Starting up CaptureBackend v X.X.XXX *
Each plugin process has its own startup line:
* Starting up Twain.Plugin v X.X.XXX *
* Starting up Vistascan.Plugin v X.X.XXX *
A session ends either when the parent process exits or when the log file rolls over due to size.
When Muntra opens the capture UI, the plugin subprocess starts and goes through an initialization handshake with CaptureBackend. This is not a scan — it is just the plugin registering itself.
In the plugin log (e.g. Twain.Plugin.log):
* Starting up Twain.Plugin v X.X.XXX *
InitialiazeRequestMessage <- CaptureBackend says hello
InitialiazeResponseMessage <- plugin responds with its paths
OpenProtoMessage <- CaptureBackend asks plugin to open
ResultResponseMessage Ok=true <- plugin confirms open
GetDeviceListMessage <- CaptureBackend requests device list
DeviceListResponseMessage <- plugin returns available devices
If you only see this sequence and nothing else, no scan was performed in that session. This is common — the logs from the plugin opened before the scan may not be the same file as the logs from the scan itself.
In the plugin log (e.g. Twain.Plugin.log)
When the user takes an image, you will see:
data transfer from Memory
buffer processing 704 x 576 pixel size 24
Followed by an ImageScanResponseMessage being sent back to CaptureBackend with the temp file path.
In CaptureBackend.log
sendImageScan handling image scan result { "ImagePath": "C:\...\Temp\xxx.tiff", "DeviceName": "VistaCam iX", ... }
sendImageScan generating new file name C:\...\CaptureBackend\Images\image-2026-03-20-09-26-54-4583.tiff
sendImageScan trying to copy from temp file for VistaCam iX ... -> ... with result True
applyImageEffects no image effects defined for this image: ...
App -> Client { "action": "scan", "successful": true, "filename": "..." }The final action: scan line is confirmation the image was delivered to the frontend.
Look for ERROR lines or missing scan events. Common patterns:
ERROR | failed to handle image scan due to ...
ERROR | failed to enable data source ...
ERROR | cannot read running.dat by path: ...
Also check if the DeviceListResponseMessage returned an empty device list — this means the device was not detected at all.
If the plugin log shows only the startup sequence with no data transfer from line, the scan was never triggered or the device did not respond.
If the scan completes without errors (action: scan, successful: true) but the image looks wrong (e.g. blue, distorted), the problem is in the image processing pipeline, not the capture itself.
Key things to check:
MultiProcessCaptureProtocol.twain, MultiProcessCaptureProtocol.vistascan, etc. in CaptureBackend.logbuffer processing W x H pixel size N. A color camera should report pixel size 24. If the wrong pixel size is reported, the conversion will produce incorrect colors.applyImageEffects shows effects being applied (CLAHE, normalization, gamma), these could be responsible. If it says no image effects defined, the image was not post-processed.The temp file created by the plugin is copied as-is to CaptureBackend\Images\ — CaptureBackend does not touch the pixel data. If the image is bad, the problem occurred before the copy.