Trend SysClean is a self-contained, stand-alone malware cleaner that can be used from the Bart PE boot CDR environment. Unlike many free cleaners such as McAfee Stinger and Avast Cleaner, it detects most things that a full-range resident av would detect, rather than a small subset of these.
On the face of it, it should be easy to run SysClean from a Bart CDR boot, but there are a few gotchas that can mess you up. If you're one who has sorted those out ages ago, yet recent found SysClean to no longer work in Bart.
Either way, read on...
How SysClean works
SysClean exists as a SysClean.com engine, plus a larger signature data file with names such as LPT%VPN.xxx, where xxx is a 3-digit number that rolls over from .999 to .000 or .001 whenever there have been that many updates. You can wildcard the data file as LPT$*.*, LPT$VPN.*, LPT$*.???, etc.
SysClean does not have to be installed before use, which makes it attractive as an intervention scanner. There is no integrated updater, so you'd manually download the latest signature data before use. As the engine is also subject to change, I'd recommend downloading a fresh engine alone with new signature data.
SysClean.com is not a true .com file, i.e. it is not a DOS-era 16-bit memory image of code that runs with all segment registers set to the same 64k space. Instead, it is a Win32 executable that unpacks itself and then jumps into itself to run.
From all of the above, you can predict pitfalls when using SysClean from Bart CDR.
The easy way to avoid these pitfalls, is to copy the files to a HD location and run them from there, all done within the same Bart boot session.
If you want to integrate via a SysClean plugin into Bart, you have to essentially automate this process, as well as avoiding a few other issues.
As SysClean writes to its own location, that location must be writable (i.e. can't run directly off the CDR) and must have enough free space to unpack (which may not be the case if running within a small RAM drive).
As SysClean.com chains into the SysClean.exe that it spawns, you must ensure your automation logic does not prematurely continue, i.e. after SysClean.com terminates but while SysClean.exe is still running. The Start /W approach is likely to fail in this way.
SysClean launches sub-tasks, and that means it may fail in environments that impose limits on the number of tasks that can run at the same time. WinPE, Bart PE and Windows XP Starter Edition may fall into this category. If you have one "wizard" batch file that launches another batch file that launches a set of scanners in sequence, then scanners that start additional processes may hit the limit.
Some of the scans are launched as sub-tasks that run in "DOS-style" CLI windows. If you used a tool within your launcher batch file to hide the batch file window, this may hide the CLI subtasks as well - creating the impression these aren't running from Bart. I haven't gone into this, e.g. removed my CLI winder hider etc. and thus am not sure the CLI scans are done in Bart, or really are skipped.
Recent failure pattern
If you've beaten all of the above problems years ago, you may have hit the following failure pattern recently...
SysClean extracts itself and runs OK, presenting you with its GUI. You then slick the Scan button and it starts scanning memory, before scanning files. But it never completes this process; even after the CD and hard drive burbling stops, it just sits there "scanning memory..." forever.
The system and app haven't crashed. If you click to stop the scan, nothing happens, but if you click the [x] to close SysClean's window, that works.
If you run SysClean again, within the same Bart session, it works perfectly!
Why does if fail the first time?
A few months ago, SysClean changed its behaviour; at the start of the scanning process, between checking memory and scanning files, it now pops up an "OK" status dialog, to the effect that no viruses were found in memory.
When run in Bart, this dialog never appears - so you can't see it and you can't click it away. And thus, SysClean will stall, waiting for an "OK" click that will never come.
Why does it work the second time?
When SysClean runs, it spawns a resident process called TSC.BIN that remains running after SysClean is done. This is spawned before the failed "OK" prompt; I suspect it's spawned as early as possible, to run as "air cover" should any active malware code try to interfere with the scanning process.
The problematic prompt is only launched if TSC.BIN is not already running when SysClean starts its scan (perhaps TSC.BIN is itself the origin of the prompt, as part of its initialisation).
So the first scan starts TSC.BIN and suffers the UI stall, whereas all subsequent scans during the same Bart session will already have TSC.BIN running and are OK.
I see one SysClean plugin approach may side-step this issue by scooping the extracted files into the plugin, rather than having the plugin run SysClean.com to extract them at runtime. This may avoid the problem if it is the extraction process that triggers the dialog - though that seems unlikely.