40% within 10 minutes..9 hours later it is still at 40%. Any known problem?
You must give us more information before we can answer any question. What type of image are you processing (E01, dd, Physical drive memory)? What is the OS of the device you are looking at? What items did you select for Aziom to process? Which version of Axiom are you using? (Axiom4.0 was just released and seem stable for what I have done)
You must give us more information before we can answer any question. What type of image are you processing (E01, dd, Physical drive memory)? What is the OS of the device you are looking at? What items did you select for Aziom to process? Which version of Axiom are you using? (Axiom4.0 was just released and seem stable for what I have done)
E01, Windows, the default (no special selection), 3.11.
I would consider upgrading to a newer version. Also, a troubleshooting tip I learned from the support staff at Magnet is during the case setup, uncheck "Uninitialized File Area" for the areas to search. See if that makes a difference
@taweret What's the status of the threads in AXIOM Process? What files are they processing? Are the file names changing or are any of the threads stuck on one file?
@tracedf they were stuck in some pst files. What could be the cause of that? We had to use FEX and start the process again 🙁
@taweret Was FEX able to process them faster? I've had issues with PST/OST files in the past. They take a long time to process. I haven't used FEX with any large ones recently, but I've noticed some other programs are slow as well; it's not an AXIOM-specific problem.
I think the issues generally are that the format is complex, the files can be large, and there is a lot of data to parse out. I don't know if some of the data is handed off to other threads (e.g. to extract metadata from an attachment), but the files seem to be processed primarily by a single thread in AXIOM. As long as there are other threads running with other data to process, it doesn't make much of a difference, you're still utilizing your hardware effectively. But, if everything else is done and you still have one thread using one core with gigabytes of PST to process, it's a bottleneck. I don't know off-hand if this would be easy to parallelize.
I had a case recently with a fairly large OST file (10 GB or more). I unchecked Outlook in AXIOM Process so that I could skip it initially. I didn't think it would be relevant and I wanted to get to be able to get some quick answers regarding some of the other items on the drive. I exported the OST later and processed it as additional evidence when I was able to let it run for a while.
@taweret Was FEX able to process them faster? I've had issues with PST/OST files in the past. They take a long time to process. I haven't used FEX with any large ones recently, but I've noticed some other programs are slow as well; it's not an AXIOM-specific problem.
I think the issues generally are that the format is complex, the files can be large, and there is a lot of data to parse out. I don't know if some of the data is handed off to other threads (e.g. to extract metadata from an attachment), but the files seem to be processed primarily by a single thread in AXIOM. As long as there are other threads running with other data to process, it doesn't make much of a difference, you're still utilizing your hardware effectively. But, if everything else is done and you still have one thread using one core with gigabytes of PST to process, it's a bottleneck. I don't know off-hand if this would be easy to parallelize.
I had a case recently with a fairly large OST file (10 GB or more). I unchecked Outlook in AXIOM Process so that I could skip it initially. I didn't think it would be relevant and I wanted to get to be able to get some quick answers regarding some of the other items on the drive. I exported the OST later and processed it as additional evidence when I was able to let it run for a while.
FEX took 6 hours to process everything. I had to cancel Axiom after almost 11 hours at 40%. The 5 PST files are pretty huge. Thanks, next time I will uncheck Outlook in Axiom, I believe that should help.
With a lot of the current tools there are certain things that cause them to be massively slower (often it's compound files of some form).
Taking some recent experimentation with NUIX, I was getting stuck on volume shadows, and it wasn't necessarily obvious they were taking all the time (became more obvious towards the end). As an example I could process the entire case with everything turned on in 1.5hrs, without volume shadows, but was 24h and still going, with them turned on. A bit of trial and error with the memory settings allowed me to complete it in the end and I would say that generally speaking you're better off with lower memory per-worker and a higher amount for the app but critically staying comfortably below your memory size (in terms of the amount committed - not just currently used). In my case I'd originally been using around 10gb per worker and 5gb for the app (with 64gb in the system). It wasn't until I raised the memory to around 30gb for the app and reduced the 4 workers to about 5gb that I could get it to complete the volume shadow. Lower amounts for the main app and it didn't seem to complete (not within 24h anyway). The problematic volume shadow itself wasn't large (under 2gb) but there were a large number of small file changes so I assume there's some sort of processing/updating of the case that more memory for the app helps with following processing by the workers. The app didn't actually appear to ever use more than 2gb judging by the visual indicators (or resource monitors) and yet this seemed to fix things.
I also vaguely remember the reverse in the past, needing a lot more memory per worker, to get a large single file Cellebrite UFDR to start processing properly.
I mention that in case it helps anyone else struggling with processing times on NUIX rather than your Axiom problem specifically.
I don't think I've encountered the same memory-related problems with Axiom but I suspect (without checking) that it probably, like most tools, will export these PSTs for processing, and therefore the location of your temp folders for Axiom process and Examine may have a significant impact. Therefore, if you've not got these on a fast drive, you could probably speed things up a lot by doing that (on an NVME SSD ideally - and obviously the larger the better to ensure you don't run out of space).
If you've got a big PST and your machine isn't super-powerful then I'm not sure 9hours is entirely unreasonable and it may actually still just be working.
Failing that, perhaps the PST is damaged/corrupted, and may require you to use something like the ScanPST tool from Microsoft to fix it prior to processing. I'm not sure how well Axiom copes with damaged PSTs (as I do less corporate work these days).
So it's probably worth exporting the PSTs individually and running Axiom over them to see how long each one takes (or whether they fail to complete). Probably starting with the smallest first and working your way upwards. At least then you'll know if it's processing them, but just slowly due to lots of data, or whether it's hanging on a problematic one.
Having moved to Axiom 4.0, I am finding that the processing is getting more and more unreliable.
The custom artefacts can cause the case to crash at the end when adding in all the additional databases it found, but generally it seems to be getting more unstable.
