Announcements
Hi,
I'm trying to import a trace file created in AX 2012R3 but I get the following error:
I can still see some of the trace data but a lot of the timing fields are obsured by overflows
We are running
- Kernel version: 6.3.6000.9100
- Application version: 6.3.3000.110
Could the different versions be the issue?
I hope someone can help me figure out how to fix this issue.
Thanks.
We are also stuck with similar issue after update of Windows to 2019 and 2022
I have it occuring on versions of Win 2008R2 , WIN2012(R2) , WIN2016 .
The newer the OS version and the more recent the server is installed it is more likely the issue will occur.
Some of my coworkers found it was only happening if the AOS was running on Windows Server 2019. Windows Server 2016 or older didn't have an issue.
Hi,
Did someone find the root cause of this issue ?
We are also facing identical errors, when importing TRACE files originated on an AX2009 AOS into the latest Traceparser.
From some AOS servers we are still able to import the files, but from others we get the arithmetic overflow.
This seems to have started about 2 years ago. More and more of our customers are facing this issue. Especially on newly (re)installed servers.
We couldn't link it to any specific AX build, OS build .
Remark : old trace files can still be imported. Only the newer ones give an issue.
Analyzing the data in the SQL database, I found that the data in
Table : Tracelines
Columns : inclusivedurationnano , databasedurationnano , binddurationnano, exclusivedurationnano , prepdurationnano , rowfetchdurationnano
are out of range, and causes the Traceparser afterwards to fail.
It seems to us the problem occurs when the tracefile is created by the AOS.
And I suspect some recent update of a system component ( like odbc-driver , .... ) could be the root cause.
Is there a tool or app to view the content of these .trc files directly ?
rgds
P Louis
Same error here. But I can't even get the trace file to open. I get this error when trying to open the trace after import.
Kernel: 6.3.6000.11033
Application: 6.3.6000.151
We are encountering the same error with the same kernel version. Did you ever find a solution?
If the trace parser can open other normal traces, then it should be issue of the trace file itself. Re-capture it. Otherwise it could be issue of the trace parser and you only need to use another trace parser on different box.
André Arnaud de Cal...
294,095
Super User 2025 Season 1
Martin Dráb
232,866
Most Valuable Professional
nmaenpaa
101,158
Moderator