How can we help you today? How can we help you today?
Andrew H
The message displays if the only reason the object is a GC root is that it's referenced by weak references, not if the only things that are referencing it are weak references. There would be no way to discover that an object has weak references pointing at Weak references are confusingly named in a way: they aren't actually references at all. They work by creating a GC root for the object you specify. Unlike normal GC roots these don't force the object to stay in memory but just act as a placeholder. These aren't 'references' in the same way that assigning a variable creates a reference: it's two separate objects. One is usually (but not always!) a WeakReference object that knows about the GC root, and the other is the target object. 'Dereferencing' the weak reference involves looking up the object pointed to by the gc root. Note that even with strong roots, there's no reason that an object which is a strong root can't have other references. If this were the case, you couldn't create a reference to an object stored in a static variable. Also note that the WeakReference class isn't the only way to create a weak reference GC root: you can create them from unmanaged code, or using the GCHandle class. The memory profiler won't show weak references in the object retention graph (as they aren't 'references' in the conventional sense), and won't count them in the distance to GC root column, so you can still use these to discover why the object is still in memory. / comments
The message displays if the only reason the object is a GC root is that it's referenced by weak references, not if the only things that are referencing it are weak references. There would be no way...
0 votes
This configuration is supported: it's very similar to Windows Vista as far as the profiler is concerned. I've just tried this on one of our VMs running 2008 x64 and I can't reproduce the problem you are having, either by running the profiler as an administrator or a restricted user. We're using the Enterprise edition, but it's not clear if that could make a difference here. The trigger process is used for running tasks as different users and for attaching to processes running in WOW64. It's started automatically on 64-bit systems that have .NET 4 installed for this reason. The error you see occurs if it fails to contact the main UI after 30 seconds. It has been known to occur in our VMs if they are very heavily overloaded (as the process was taking more than 30 seconds to start) The trigger process is not run if you don't have .NET 4 and don't perform any actions that require elevation. It communicates with the UI via an IPC pipe. I'm assuming from your description that this problem is occurring before the 'start profiling' dialog is displayed (it's likely to be an elevation failure of some kind if it's happening later) Are you running ANTS as an administrator or a restricted user? If you're running as an administrator, is UAC turned on? If you have task manager running while you're starting the profiler, do you see the RedGate.Profiler.Trigger process starting? Has it quit or is it still running at the point that ANTS displays the error? If it's the _x86 variety of the trigger process, is it actually running as a 32-bit process? (This is a long shot, but if this was running 64-bit for some reason then you'd see this error) / comments
This configuration is supported: it's very similar to Windows Vista as far as the profiler is concerned. I've just tried this on one of our VMs running 2008 x64 and I can't reproduce the problem yo...
0 votes
Hi, ANTS shouldn't miss any methods when using any of the 'all methods' profiling modes. However, there are a few options that can change how this is presented to you: If 'Enable Inlining' is on (it is by default), then .NET may inline certain methods, which the profiler will report as taking no time as a result. These will only show up in the results (in orange) if you have 'hide insignificant methods' turned off. 'Simplify complex stack traces' can sometimes results in method disappearing. Turning this option off might result in the profiler using up too much memory and crashing the target application. If 'avoid profiling extremely trivial functions' is on, then the profiler will save disk space and memory by ignoring methods with an infinitesimal effect on the result (this generally means property accessors that are only called once). If you're using sampling mode, be aware that the profiler won't be able to see function calls that take place in an interval less than the sampling period - generally anything that takes less than about 2ms to complete; about 99% of .NET function calls actually fall into this category. It might also be the display options: to see everything make sure that you've selected an 'any methods' display mode and turned 'hide insignificant methods' off. / comments
Hi, ANTS shouldn't miss any methods when using any of the 'all methods' profiling modes. However, there are a few options that can change how this is presented to you: If 'Enable Inlining' is on (i...
0 votes