Forum Discussion

alexarl's avatar
13 years ago

Blue screens



I have AQTime version 7.30.537.64.

Try to profile (performance profiler) our framework infrastructure.

I already did it using previous versions of AQTime some time ago (2-3 years), with then-up-to-date versions of Visual Studio, Windows XP 32 bit and AQTime, and it worked OK.

Now, I want to repeat the process with VS 2010 SP1, Windows 7 Enterprise SP1 64 bit and our new version - and it just does not work.

On one computer (i7, 8 cores, 8GB RAM) it succeeds to measure times (elapsed time only, else it crashes), but usually crashes into blue screen or application crash when I operate AQTime software (change sorting order, add / remove filters etc).

If I try several times I can get some results before it crashes, but I can't call it "stable software".

On the other computer (Quad CPU Q9400, 4 cores,4GB RAM) AQTime session exits with "critical error detected c0000374".

So I abandoned the idea to profile our release version, and tried to profile debug build of our app.

Now it worked (at least profiling session of 3 minutes completed normally).

Then I got blue screen when I tried to enter "HitCount" filter.

Application is small benchmark application over our infrastructure package, and works perfectly both in release and debug configurations outside of AQTime. (all .Net managed code).

So I get two different patterns on different computers, and on both completely unusable software.

I hate to write it, but 95% chances we are moving to another profiling tool.

4 Replies

  • Hi,

    To help us investigate your problem, please contact our Support Team and send them the following information:

    1. The profiling project you are using.

    2. The profiled application.

    3. Dump files generated when errors occur. To generate the dumps, follow the steps below:

    1) download the Debugging Tools for Windows package from:

    and install it;

    2) when an error occurs in AQtime, open the "Start | Run..." dialog and execute the following command:

    "C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe" -pn AQtime.exe -Q -pd -c ".dump /m C:\TCDump1.dmp;q"

    This command will make WinDbg write a memory dump of the AQtime.exe process to the "C:\Dump1.dmp" dump file. After the dump is written, WinDbg will be closed;

    3) if your tested application is still running (check this via Task Manager), generate a memory dump for its process as well:

    "C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe" -pn APPLICATION_PROCESS -Q -pd -c ".dump /m C:\AppDump1.dmp;q"

    (change APPLICATION_PROCESS to the actual name of the tested application's process that you can see in Task Manager);

    4) wait for two minutes;

    5) repeat steps 2-4 twice more (but correct the dump file names in the command lines);

    6) send us all of the generated dump files.

  • vbazarov's avatar
    New Contributor
    Don't you hate those boilerplate replies?  It's a BLUE SCREEN.  Kernel panic.  Happens to me with AQtime and "User Time" or "User+Kernel Time" counters on Win7/64 *all the time*.  And there is no way to predict when it's going to happen or recall what I was doing.  Yesterday, for instance, it happend *four times*, one of them I wasn't even running the application, just sitting there browsing the results in AQtime.

    Don't get me wrong, AQtime is a great product with very useful features, like the triggers, or selective profiling of only the loaded modules (VTune used to do that, where is it now?) but why can't they make it stable enough to be useful on a multicore multiprocessor machine?  Elapsed time counters are almost meritless; I get 20-30% variation in results from two consecutive runs of my app with everything else the same, if I use the Elapsed Time counters, and I'm forced to use those because if I try the User Time, I get bluescreens.  Random bluescreens.  Those cost me not only data loss (yes, frequent project saves do help), but I also lose time because it takes several minutes for my machine to reboot, start AQtime again, and load a project... (any improvement expected in the instrumentation process?  I have 23 cores sitting there doing nothing when your single-threaded instrumentation is chugging along processing a large complex DLL of ours...)
  • vbazarov's avatar
    New Contributor
    Just in case somebody sees this thread first, see FAQ.  I am about to try running with the User+Kernel Time counters in the Debug mode of the OS.  Curious how slow that's going to be...
  • vbazarov's avatar
    New Contributor
    User+Kernel time counters worked fine in Windows 7 with Debug mode ON (see the FAQ).  Of course, I can't run Skype while in Debug mode, but at least I managed to profile several scenarios, and moving on with the project.  I wonder whether it would be possible to run AQtime on a virtual machine with debug mode on, and how [in]accurate those results are going to be...