Answer by Tomasz S. ·
It took me a while, but I finally dug into the problem and here’s an interesting thing I’ve learned: DNA manages memory differently, depending on the trace format used.
When importing an .opx trace (or another within the family), DNA tries to map chunks of file into memory with MapViewOfFile (https://msdn.microsoft.com/en-us/library/windows/desktop/aa366761(v=vs.85).aspx). This means that it cannot load a trace larger than its address space (minus RAM used to display GUI and other needs). Since this is a 32-bit application, the realistic upper bound for importing an .opx trace should be considered to be about 2-3 GB. (Performance will probably be unacceptable, so we’re only talking theory.)
When it comes to dealing with third-party formats such as pcap, DNA resorts to other libraries to do the parsing and load the entire trace into memory as one big chunk using GlobalAlloc (https://msdn.microsoft.com/en-us/library/windows/desktop/aa366574(v=vs.85).aspx). With the ad-hoc instrumentation I made on my machine, I found the actual upper bound to be variable, between 300-700 MB, supposedly due to memory fragmentation.
Now what it means for you is: when you have a large non-opx trace and want to import it into DNA console regardless of the warnings, you can:
The former sounds definitely like a better plan. We have a small command-line trace conversion utility which can do the former without any significant overhead; I guess I could share it if need be. Let me know if this is an acceptable solution.
EDIT Added trace conversion utility: makeopx.zip. Extract to DNA console installation directory. When run with a path to trace file as an argument, it loads it into memory and then saves an opx equivalent under the same name with an .opx suffix.
Answer by Tomasz S. ·
We have a tool designed specifically for dealing with large traces – this is the Trace Trimmer tool installed together with DNA console (you can find it in the Start Menu). It allows you to browse trace contents and decide on which portion of conversations or protocols you want to analyze further. You can also pick a time range at this point, which would make the output trace smaller and let you focus on the actual transactions.
While the above recommendation is worth trying anyway, you mentioned “file format not recognized”, which may lead us somewhere else. Where does this trace come from?
Answer by Ulf T. ·
DNA is a transaction oriented tool. If you really have a single transaction that is over 300 MB then I have to say I'm impressed :-)
That said I have 2 questions:
Where is your DNA - Is it standalone on your desktop or is it in your server?
At what stage does it fail?
Time Sync on Merged Traces 2 Answers
Interpreting Captured Trace Data 5 Answers
DNA - SQL protocols decoding 1 Answer