Comments
Sort by recent activity
I'm looking into this today. I don't have a reproduction yet so I can't be specific.
However, this particular error is usually caused by a problem with the instrumentation added by the profiler. We had previously only seen this occur when an instrumented assembly was further modified by reflection, though we've seen a lot more reports of this in other situations recently (I'm not sure why, though I suspect that what's changed is that more people are using 64-bit systems, which has different JIT error checking behaviour to 32-bit systems)
It's likely that turning off line-level timings will stop the error occurring. I think this issue is more common on 64-bit systems, so an alternative approach might be to try reconfiguring the application to run in a 32-bit application pool. / comments
I'm looking into this today. I don't have a reproduction yet so I can't be specific.
However, this particular error is usually caused by a problem with the instrumentation added by the profiler. We...
Hmm, I'm not able to reproduce this problem: by itself the AjaxControlToolkit dll seems fine. What other third-party components are you using with your website?
It's also possible this is a trust issue: to do line-level timings, the profiler requires that an assembly be loaded with full trust. The AjaxControlToolkit DLL comes in a zip file that marks it as a file from the internet zone, which usually causes .NET to reduce the trust level.
Could you try the following command from a command prompt in a folder containing the dll: more < AjaxControlToolkit.dll:Zone.Identifier
If you see something like this, then it's likely that the DLL is untrusted: C:\Inetpub\wwwroot\AJAX2\Bin>more < AjaxControlToolkit.dll:Zone.Identifier
[ZoneTransfer]
ZoneId=3
/ comments
Hmm, I'm not able to reproduce this problem: by itself the AjaxControlToolkit dll seems fine. What other third-party components are you using with your website?
It's also possible this is a trust i...
There are two possibilities for this error: either there is a problem with WMI on your system (we use this to determine the process ID of the service if it's running), or ANTS is unable to determine the registry key for your service. The latter is more likely, I think.
The service should have a key at HKEY_LOCAL_MACHINE\CurrentControlSet\Services\<Name>, where <Name> matches the name in the drop-down, which should in turn have an ImagePath key. If it's missing, then it looks like ANTS will give this exception (though if it's missing it's odd that the service is able to start at all). It's possible that ANTS is case sensitive.
If the key is not present, or the name doesn't exactly match the list, can you let me know what the difference is?
You might be able to fix this problem by deregistering and reregistering the service. / comments
There are two possibilities for this error: either there is a problem with WMI on your system (we use this to determine the process ID of the service if it's running), or ANTS is unable to determin...
They should, and the profiler tidies them up when it shuts down a session with IIS. Unfortunately there's no opportunity to do this if the UI suffers an unexpected shutdown, so the keys will remain in this case.
The message is annoying but harmless (it will show whether the profiler is installed or not: the profiler core will refuse to load when it's not needed).
It's not easy to decide what the right behaviour is when this has happened: as the condition has arisen due to a failure, it's possible that attempting to clean up later on could compound the problem and obfuscate the cause, which would be bad for a service like IIS.
We've been considering an alternative approach for IIS 6 and later, which is to set the variables via an ISAPI extension. The main disadvantage for us with this approach is that it won't work with IIS 5 due to the way that ASP.NET is started there, so we'd still need to maintain the old method for as long as we support Windows XP. It also depends on knowledge that IIS initialises things in a certain order, so it would have the potential to mysteriously stop working with a Windows update (or if the extension was disabled somehow) / comments
They should, and the profiler tidies them up when it shuts down a session with IIS. Unfortunately there's no opportunity to do this if the UI suffers an unexpected shutdown, so the keys will remain...
Hmm, this definitely sounds like a bug of some variety. We didn't change this area of the profiler very much in v5, so it's surprising anything has changed [image]
We use the same data for both views so the results should be the same, provided a method is hit only in one place.
If you flip the CPU time drop down back and forth, does the issue go away? I think v5 had a bug where this could get out of sync for the all methods view.
If that doesn't work, which profiling mode are you selecting when this issue occurs?
There's a bug in v6 that occurs when opening results from older profilers that might be the issue you're seeing here. If you click the 'time with children' header in the all methods view to change the sort ordering, do the bar graphs stop lining up with the results? / comments
Hmm, this definitely sounds like a bug of some variety. We didn't change this area of the profiler very much in v5, so it's surprising anything has changed
We use the same data for both views so t...
.NET 4 support is still fairly experimental in both profilers; unfortunately this means there are still likely to be some bugs. In this case, it looks like some of the changes made to the CLR have caused the code that reads strings from memory to fail, so the values are not available. Other field values are still available, however. We're currently planning on updating the profiler to fully support .NET 4 once Microsoft has made the final release available.
You should still be able to determine what the strings are being used for by looking at the class reference explorer (for the string class as a whole; it can also be used to help narrow down the instance list to specific sets of strings) or the object retention graph (for a specific string). / comments
.NET 4 support is still fairly experimental in both profilers; unfortunately this means there are still likely to be some bugs. In this case, it looks like some of the changes made to the CLR have ...
We've got one bug in our tracking system that might be this issue. The situation it occurs in is a little complex:
* You need to be running a 64-bit version of Windows
* The COM+ component should be installed as a 32-bit component
* It must also be configured with an 'Any CPU' platform target
* Communications with the component must be from a .NET application using COM+ interop
The current version of ANTS will see that the component can be launched with a 64-bit server process and will do so without paying any attention to the way the component is actually installed. Almost everything works in this situation (oddly enough, including 32-bit native applications which you'd expect to be most likely to fail), except when a .NET application tries to use COM+ interop to communicate with the component - it tries to switch to .NET remoting and due to an interaction that's pretty bizarre gets confused when it finds that the component is running in 64-bit mode and reports the error that you're seeing.
You can work around the issue by ensuring that the component is installed as 64-bit, or by changing the project configuration so that the platform target is set to x86 (the former fixes .NET's behaviour, and the latter fixes ANTS). We've scheduled this particular bug to be fixed for version 6. / comments
We've got one bug in our tracking system that might be this issue. The situation it occurs in is a little complex:
* You need to be running a 64-bit version of Windows
* The COM+ component should b...
The profiler is set up so that if a snapshot fails for any reason it tries to shut down the session. The error reporting isn't set up quite right: if the shutdown then fails, the original error is lost and the shutdown error reported instead (I've raised a bug about this; it's incorrect behaviour as the error is secondary and isn't any help in fixing the condition).
In this case, the profiler is detecting the condition that is caused by the gcServer issue and reporting it as a reason for failing the snapshot to the UI, which then shuts down the session in response. / comments
The profiler is set up so that if a snapshot fails for any reason it tries to shut down the session. The error reporting isn't set up quite right: if the shutdown then fails, the original error is ...
The profiler does perform several actions that can cause additional load on the JIT that it won't fully account for: in particular, it needs to add instrumentation and read debugging information. The instrumentation is particularly difficult to compensate for, as there's no way to know the time to compile a method without it.
This can be especially slow if the pdb or source files are located on a network drive.
There's no way to entirely eliminate this overhead, but you can reduce it by changing the profiler options. Switching to using one of the method-level modes will have the biggest effect, as it cuts down the amount of instrumentation significantly. Disabling the 'include source code with saved results' option will also increase JIT performance somewhat.
The biggest time waster after this is the time taken to read the debugging data for each function: unfortunately this can't be helped other than by removing PDB files for assemblies that you don't want source code information for. / comments
The profiler does perform several actions that can cause additional load on the JIT that it won't fully account for: in particular, it needs to add instrumentation and read debugging information. T...
Build 663 of the EAP is now out, and should hopefully address the issues on x64. http://downloads.red-gate.com//EAP/ANTSPerformanceProfiler/ANTSProfiler_6.0.0.663.exe
justsml wrote:
I'm running into a similar issue with bizarrely random code execution - things like:
"Hello".IndexOf("o")
However, this is something I can't reproduce here even with older versions of the profiler. The bug that we found specifically affects methods that return floating point values on x64 systems. / comments
Build 663 of the EAP is now out, and should hopefully address the issues on x64.http://downloads.red-gate.com//EAP/ANTSPerformanceProfiler/ANTSProfiler_6.0.0.663.exe
justsml wrote:
I'm running int...