I'm trying to debug some CPU issues caused by a .NET 4.6 MVC5 application by analyzing a dump created by DebugDiag 2.1.0.7. I'm finding even after loading custom .pdb symbols I'm still not getting stacktrack information in the generated report:
The error that the report displays is
Type: Microsoft.Diagnostics.Runtime.ClrDiagnosticsException
Message: This runtime is not initialized and contains no data.
I note that DebugDiag version 1.2 didn't support .NET 4.0+. Could DebugDiag 2.1 perhaps not support .NET 4.6?
My CPU issues came down to a third-party piece of software that I was initialising in the wrong place. It needed to be initialised in Application_Start() and instead I was doing it in Application_BeginRequest(). Whoops! If you're experiencing this, and are scrambling around trying to debug issues in your production app like I was, make sure you check out the Global.asax for anything like this.
I'm guessing that the StackTrace issues with DebugDiag were related to where in the application lifecycle that the code causing the CPU problem was occurring.
Related
I've recently started using .Net 5 on Mac, and I've discovered that Console.Beep throws an 'unsupported operation' exception.
Do the standard libraries provide a working way to make sounds for Mac? I do not believe they did in .Net Core, as per: How to play a sound in NETCore?
TLDR: From further research, I believe the answer is NO.
I discovered the System.Media.SoundPlayer class (which is in .Net 5.0), but I got a compile error System.Media belonged to missing assembly System.Windows.Extensions.
I found and installed this via Nuget: https://www.nuget.org/packages/System.Windows.Extensions/
My application now compiled but upon trying to call SoundPlayer.Play() I got PlatformNotSupportedException -
"System.Windows.Extensions types are not supported on this platform."
I can't see in the documentation anywhere if .Net 6.0 will change this though.
If I try to deploy and debug my windows 10 mobile app, the debugging stopped with error:
It only happens when I set Native debugging. Managed debugging doesn't cause such error.
It is stated here that .NET Native debug engine has some capability differences from normal .NET debugging. Furthermore, it is recommended to debug a non-optimized code:
These optimizations will have a significant impact on the debugging experience including unpredictable stepping and breakpoint behavior (due to code inlining) and the inability to inspect most variables due to memory optimizations.
Although this was not your presented case, it still pushes further to the following practical solution:
This means you will want to debug a non-optimized .NET Native build. This fastest way to do this is simply to disable optimizations.
Source
I'm trying to rewrite IL code dynamically at runtime. While this is quite well documented for .NET framework applications by using the Profiling API I can't find anything similar for UWP applications.
Because I have a suite of automated function tests, I need to setup the profiling environment and start a sample app programmatically.
Attempt 1
This question explains how to enable a debugger (as far as I understand a profiler is essentially a debugger) and programmatically start a UWP app.
So from my bootstrapper I call IPackageDebugSettings::EnableDebugging followed by IApplicationActivationManager::ActivateApplication.
Anyway I can't figure out how to implement the debugger. The debugger (which is an executable) is called with the following arguments:
-p 3836 -tid 6180
Both numbers change on every run. While p seems to be the process id of the debugged process, I have no idea what tid could be or how I have to use the arguments to control the debugged app (register for module load events, trigger rejits etc.).
Attempt 2
I found this issue on the Core CLR repo which is about enabling the Profiling API for Core CLR apps. The issue contains a link to a sample profiler repo.
So profiling for Core CLR apps seems to basically work the same way as it does in .NET framework apps (with some restrictions). From my bootstrapper I tried to set the appropriate environment variables (i.e. CORECLR_ENABLE_PROFILING, CORECLR_PROFILER and CORECLR_PROFILER_PATH) followed by IApplicationActivationManager::ActivateApplication.
However the profiler doesn't attach.
I'm quite sure that in general it is possible to profile UWP applications because JetBrains' dotTrace can do it.
Any ideas?
I am getting this exception when I process a WCF request from my Xamarin.Forms app:
"Attempting to JIT compile method '(wrapper runtime-invoke) :runtime_invoke_bool_Nullable`1 (object,intptr,intptr,intptr)' while running with --aot-only.
See http://docs.xamarin.com/ios/about/limitations for more information.\n"
Please, how could I fix this? I have checked the server side but it seems ok.
The rest of WCF requests are working fine and this only happens in devices (not in simulator).
This is happening only in iOS, in Android it works fine.
Thanks.
iOS does not allow dynamic code generation / JIT'ing, everything must be AOT compiled... An Apple security restriction for all apps, JIT'ing within their own Nitro JavaScript engine is an exception to that rule.
Xamarin explains it very well in the link that is provided via the exception:
No Dynamic Code Generation
Since the iPhone's kernel prevents an
application from generating code dynamically Mono on the iPhone does
not support any form of dynamic code generation. These include:
The System.Reflection.Emit is not available.
No support for System.Runtime.Remoting.
No support for creating types dynamically (no
Type.GetType ("MyType`1")), although looking up existing types
(Type.GetType ("System.String") for example, works just fine).
Reverse callbacks must be registered with the runtime at compile time.
Ref: http://developer.xamarin.com/guides/ios/advanced_topics/limitations/#No_Dynamic_Code_Generation
I've reached the stage where it's time to start tracking down memory leaks and, to my dismay, Instruments is giving me very little to go on (other than the fact that I definitely have leaks). My stack trace contains no information other than memory addresses.
Since I'm working on a new project and I've transitioned to version 3.2.1 of Xcode in tandem, I'm not sure if it's my program configuration or Xcode that's causing the problem. I have found one reference to the issue coupled with a post on the dyld leak that seems to be prevalent with the 3.2.1 release.
Since I haven't been able to find much on the problem I'm guessing it's something I've created rather than a systematic issue with Xcode. If someone has any idea where I might have thrown a wrench in the works, I would love some pointers. Also, if someone could just verify that the stack trace is indeed functioning properly in 3.2.1 that would be useful as well.
Are you trying to run Instruments with a Release build of your app? If so, you might be stripping symbols so Instruments can't find them. Check that you're using a Debug build.
Based on irsk's suggestion, I did a little searching and this appears to be an ongoing issue with symbolicatecrash. I came across a post mentioning that another user was having problems with 3.0 debug builds exhibiting the behavior, but 3.1 was working fine (I've been using 3.0 debug).
So I did a little testing:
Simulator - 3.0 | Debug (address space only in Instrument, i.e. no symbolic linking)
Simulator - 3.1 | Debug (Instruments fully functional)
Simulator - 3.1.2 | Debug (Instruments fully functional)
It would appear the work around is to avoid 3.0 builds in Instruments.