Occasionally the UnhandledException handler in my app is raised due to an unhandled XAML exception.
The UnhandledExceptionEventArgs contains the message
E_RUNTIME_SETVALUE
and an inner-exception of type ArgumentException
Value does not fall within the expected range.
There is nothing in the call stack other than InitialiseComponent() which I can step into/ over without any exception being thrown.
Any ideas on how to debug further or any experience with E_RUNTIME_SETVALUE issues?
I do remember I had to once add basically no-op value converters to some XAML so I could see what was going on and trace the error. That might help in this case as well.
Also try to turn on mixed-mode debugging to see if more data comes from the native stack.
I had this in UWP and it was because I was using OnIdiom
<OnIdiom x:Key="MyFontSize" x:TypeArguments="x:Double" Tablet="28" Phone="16">
</OnIdiom>
I didn't have desktop included in one of the values and I was running my app on my desktop.
Related
Using Google Cast Remote Display API in an iOS game (NOT unity) and I see this in my crash logs (haven't been able to reproduce it on my end)
0x1002162b4 media::cast::AdaptiveCongestionControl::EstimatedAckTime(unsigned int, double) + 4296794804
0x1002163c8 media::cast::AdaptiveCongestionControl::EstimatedSendingTime(unsigned int, double) + 4296795080
This is in a crash:
com.google.cast.io EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008
Any ideas? It does not seem to happen to a lot of users so far.
Based from this forum, maybe it is due to GCKDeviceManager being deallocated during postNotificationName:object:userInfo:. Try to swizzle into NSNotificationCenter, and see that the postNotificationName dies, and that GCKDeviceManager was trying to remove its own subscriptions.
Also found this thread which states that:
"Unless indicated otherwise, the caller should not release the delegating GCKDeviceManager object from within a delegate method." I found where the rule was not being adhered to. A change to delay setting our reference to the GCKDeviceManager makes the crash go away.
Hope this helps!
I am running my application in VS2012 and I am getting a runtime error;
When I look in the "Original Location" I see mscorlib.dll, but not mscorlib.pdb.
Why is this happening and how do I fix it?
Goto Tools, Options, Debugging, General, Enable Just My Code
This will prevent the debugger from trying to launch on a Internal .NET Framework Assembly.
Goto Tools, Options, Debugging, Symbols and set a cache location. Then hit load in the above and it will fetch the necesary symbols for you and store them in the cache location you provide.
Microsoft's compiler tools create symbols in separate files with a .pdb extension (program database). This allows them to create detached symbols for release binaries. With a symbol server, your IDE can fetch the symbol file matching the specific version of the DLL during debugging. You can configure this system for your own product binaries as well which can be very useful for post-mortem debugging any crashes on end-user machines.
See Microsoft's documentation for more details about using their public symbols.
I had this issue when I was using a static variable, whose value is assigned off a static method.
So, whenever I ran the application, this line of code threw exception. If you place a debug point on this (like I did), you will notice the exception being thrown.
The best Solution to solve this error is:
1: Open App.config file.
2: Paste this useLegacyV2RuntimeActivationPolicy="true" code in the startup tag.
3: Save it.
Now the error would disappear.
Moreover see Image. I have done this for you.
This happened to me for a different reason: I had referenced an old version of NLog (2.0) and needed to reference version 4.0, instead.
In a VB console app, in my case it was none of the above.
Just doing a string calculation in the Dim declarations before my subs.
The offending code:
Dim FylPrefix$ = Fyl.Substring(0, Fyl.LastIndexOf("."))
Moving this calculation into the sub it was needed in fixed it! GERONIMO!!
This can happen when you initialize a variable in your class declarations and that initialization throws an exception:
class Program
{
static OracleConnection ora = getOracleConnection();
}
static void main(string[] args)
{
ora.Open();
}
static OracleConnection getOracleConnection()
{
OracleConnection orax = new OracleConnection(description=(host=myHost)
(port=1521)(protocol=tcp))(connect_data=(sid=mySid)));user id=user;password=pw;
}
If an exception is thrown by getOracleConnection() you can get this error. Move your assignment (but not necessarily your declaration) inside of main (where it belongs anyway), and you will get the actual exception that is causing the error instead of the mscorlib error.
In my case the exception began to appear after I changed the "Assembly name" in the "Application" tab of the properties window. If that's the case with you try reverting to the original name and see if the exception disappears.
Perhaps the reason for this was that the new name did not match the AssemblyTitle in AssemblyInfo.cs.
if you have this type of project runtime error in visualstudio
Answer:Cntr+Alt+E open Exception window Uncheck All chechboxes
Must and shoud its working written by B sriram Mca Giet College
rajahmundry, east godavary ,2014 batch
I notice Debug.Assert does not trigger in Metro apps, however, if the project is a traditional one like Console or WinForm, it does trigger. And yes, I am in Debug mode.
Is it a setting not properly set in Visual Studio (11 Beta)? Or Debug.Assert is intended to be disabled in metro apps?
I know many exceptions are swallowed during the execution of Metro apps, but Debug.Assert is so handy that I can't think of a reason why it should be disabled.
Seems like a bug. I would roll out my own assert method. Something like:
[Conditional("DEBUG")]
public static void Assert(bool condition)
{
if (!condition)
System.Diagnostics.Debugger.Break();
}
It does trigger, look in the Output window. It just doesn't automatically prompt you to ask if you want a debugger break and thus just keeps motoring.
The DefaultTraceListener.AssertUIEnabled property is false. That's an implementation problem, can't display a message box on top of Metro UI. Which does actually work but the monitor switches to the desktop, pretty undesirable when you would have liked to click No. Hard to solve and no doubt on the todo list. You can't easily get to the property to set it to true, it is inaccessible from the metadata. Filip's workaround sounds half-decent.
There is the same problem with F# in WinRT, in VS2013. The assert statement, which is an alias for System.Diagnostics.Debug.Assert, does not raise an exception, so unless you are watching the Output window then your assertions can fail without being noticed. Even if you are watching, it is hard to find the spot where the assertion was raised.
I followed Filip's suggestion and wrote a short utility, as follows:
namespace MyProj.Infrastructure
module Diagnostics =
let Assert condition = if not condition then
System.Diagnostics.Debugger.Break()
I chose Debugger.Break over raising an exception because it stops the debugger at the place the assertion fails. However, raising an exception is an acceptable alternative.
I didn't have any suitable global projects or modules already in my solution, so I had to create them just for this, which was quite annoying.
I have an OpenSL ES function call that causes no problems in one application, but causes a problem in another application, both run on the same device.
The line is:
result = slCreateEngine(&engineObject, 0, NULL, 0, NULL, NULL);
Where result is of the type SLresult, engineObject is of the type SLObjectItf
The error I seem to get is:
05-19 11:56:27.007: ERROR/libOpenSLES(1425): slCreateEngine while another engine 0x299fa0 is active
It seems this is not logged from my code, but maybe it is caused by it? So what could cause this line to produce an error in one app, but not in the other?
As it happens to be, it was partly Android's Activity life-cycle which caused the error, but mostly my own fault. It was caused by the onCreate() and onResume() methods Android provides for an Activity. I never thought of the fact that onResume() also get's called when an Activity is started. Because of this, I never realized that I had a 2nd call to the slCreateEngine function.....
According to the docs "OpenSL ES for Android supports a single engine per application". I had a quick check of the source for OpenSL an I can see this is enforced by a global storing the current active engine.
So if you want to call slCreateEngine, you must make sure all other engines have been destroyed first. This includes the possibility of any 3rd party code you are linking in too (incase you are linking in something else that is creating an OpenSL engine object before you do).
See http://support.microsoft.com/kb/312629/EN-US/
I am using reponse.direct in my app as well and I am not getting the exception. The workaround that the knowledge base article suggests (Server.Execute) does not work for me. I am getting lots of javascript exceptions from the Ajax Toolkit on the target page if I use Server.Execute, and I did not dig into the cause.
My question - what arguments do you see against just swallowing the exception as a 'known limitation' and moving on?
My reason for using Server.Transfer in this one very specific case is that I want to mask the (real) target url of the page that is actually executing. It works pretty well, except for this exception (that the user never sees).
Make sure you are not calling Server.Transfer() within an exception handler (try..catch/finally).
Edit:
Server.Transfer always raises ThreadAbortException upon completion. If you wrap it in an exception handler you should trap for explicit exception types instead of just 'Exception'.
See the help for Server.Transfer on MSDN. Here is info about ThreadAbortException