Struggling with an error that freezes the app and only occurs on the tablet (never on my laptop). Seems to be related to quickly switching the hamburger menu. I got one stack trace that incriminated a 3rd party control, but 9 of 10 times all I get is the following. There are only a couple of "async void"s where I can't avoid them (overriding events) and from other logging, I believe the issue is in the XAML (methods are logging entry/exit):
Unspecified error
: System.Runtime.InteropServices.COMException (0x80004005): Unspecified error
Unspecified error
at Windows.ApplicationModel.Core.UnhandledError.Propagate()
at Oceaneering.Commons.Utilities.Logger.CoreApplication_UnhandledErrorDetected(Object sender, UnhandledErrorDetectedEventArgs e)
Setting up like this:
CoreApplication.UnhandledErrorDetected += CoreApplication_UnhandledErrorDetected;
And the receiving method is:
try {
e.UnhandledError.Propagate();
}
catch (Exception ex){
logChannel.LogMessage(string.Format("Unhandled Exception: {0}:{1}", ex.Message, ex.ToString()));
SaveToFileAsync().Wait();
}
Anything else I can do to gather more info? Thanks!
As the author confirms in a comment below the question itself, the error can be resolved with a NuGet update.
Check dependencies and version history at:
https://www.nuget.org/packages/System.Runtime.InteropServices/
Related
Alright, this is probably the biggest program i have ever written. I use task in it once so that on first run it will search all available files and folders for certain things. Everything works...well, did work. Now when i start the program after adding a few more features in. It is throwing stack overflow errors on things that never had a problem before.
My first one was right in the begging it threw on a simple return of,
return System.Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments)
i changed it to just return
public string BaseUpdaterPath { get { return "C:\\Users\\Public\\Documents"; } }
and it started working again.
it got alittle further into the program untill it runs a check to see if a specific path exists.
if (File.Exists(pathINI))
pathini is defined earlier as
string pathINI = (BaseProductPath + "\\" + Name + ".ini");
and baseproduct is
public string BaseProductPath { get { return BaseUpdaterPath + "\\" + Name; } }
these are things that should not be breaking. My error is this
An unhandled exception of type 'System.StackOverflowException' occurred in mscorlib.dll
with more investigation turns into this
Source Evaluation of method System.Exception.get_Source requires calling method System.Reflection.RuntimeMethodInfo.CreateDelegate, which cannot be called in this context. string
I can only imagine this has something to do with threading and the initial search that I am doing if this is the programs first run time.
If i can provide anymore information that i may have overlooked in my details i would be happy to provide it. I have not seen errors like this before that don't really give you much to go off of.
I may just end up throwing up a splash screen during that initial search if it's going to keep causing problems like this and have the rest of the program wait on that task.
UPDATE
I just stepped through my program starting at different steps and i was able to get past that check it kept kicking it out at. Then i got to a different if(foo == bar) and visual studio did this strange thing where it popped up a little loading window and said evaluating BAR then killed the program with
has exited with code -2147023895 (0x800703e9).
wtf is going on lmao
Another update incase anyone runs into this. I have a product preselected when i started up the programming, i wrote checks in to accommodate this however....it blocked me from being able to see what is really happening.
I disabled some code and let the thing run and after a while i found this little bastard popping up on the console
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
Exception thrown: 'System.IO.PathTooLongException' in mscorlib.dll
now i gotta track that down to wherever the hell it's throwing 5000 times and i should be good to go.
Update again if anyone cares.
I found out that even i caught and threw the exception away it was still getting stackoverflow in windows.old because they have tons of folders and files and i was running out of memory. My solution at this point is during the recursive file check to just discard anyfolder in windows.old. Cant think of a better way.
THE EPIC CONCLUSION...I AM A DUMBASS
i was having two properties check eachother
public bool IsInstalled { get
{
if (DefaultInstalledpath != null || DefaultInstalledpath != "Not Installed")
{
return true;
}
else
{
return false;
}
}
public string DefaultInstalledpath
{
get
{
else if(!File.Exists(pathTXT) && IsInstalled == true)
{
return "Discovering! Please Wait...";
}
.........
i don't wanna talk about the rabbit hole i just fell down
We have a number of sections of code in the format:
try
{
// code
}
catch(std::exception &e)
{
// log exception
}
catch(...)
{
// log unknown exception.
}
Every so often, the unknown exception code triggers, and logs an unknown exception.
I always thought that all exceptions were meant to derive from std::exception, and thus catching std::exception would catch all exceptions.
Is there some other exception that I should be catching?
If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
edit
We managed to locate the cause of the problem- despite saying that they had, the customer had not installed .NET 3.5, which our code depends on, and the system fell over when trying to use the XML parser.
Is there some other exception that I should be catching?
This depends on your code. Libraries you call can throw exceptions not derived from std::exception, examples are MFC's CException or Microsoft's _com_error. Also, an access violation might be catched by catch(...), which is the reason why I would not use catch(...) in my code - it's just to broad for me.
2.If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
You can run your code in the debugger and configure the debugger to break your program when the exception is thrown (first chance). Then you know exactly which line of code triggers the exception and should be able to see what exactly is thrown.
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.
I implemented a custom AbstractJavaSamplerClient for JMeter, and the core runTest is like:
SampleResult results = new SampleResult();
results.sampleStart();
client.request("connector.ninjaHandler.savemove", opMsg, this);
while(optcode == null){
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
results.sampleEnd();
results.setSuccessful(optcode);
However, I found Thread.sleep() will cause such exception:
Uncaught Exception java.lang.IllegalStateException: Timer already cancelled.. See log file for details.
I googled around and people say thread.sleep will cause the timer failed. However, I cannot avoid it since I'm testing a web-socket server, which means I need to wait the server response back...(It runs OK if I delete the thread.sleep between sample start/end)
However, the sample test org.apache.jmeter.protocol.java.test.SleepTest works well, which use the thread.sleep.
Any suggestions?
It is quite ridiculous since I found the problem comes from the library that I use...
After fix the patch from here, it works!
How can I stop a Gradle build after detecting a problem? I can use an assert, throw an exception, do a System.exit (bad idea), or use a dedicated function in Gradle (but I could not find one). What is the best way for Gradle (and why?).
I usually throw the relevant exception from the org.gradle.api package, for example InvalidUserDataException for when someone has entered something invalid, or GradleScriptException for more general errors.
If you want to stop the current task or action, and move on to the next, you can also throw a StopActionException
If you want to stop the build, throw:
throw new GradleException('error occurred')
or throw the subclasses for the above exception. Some of the subclass exceptions actually only fail the current task but continue with the build.
There is currently no dedicated method, although there have been discussions to add one.
The recommended way to stop a Gradle build is to throw an exception. Since Groovy doesn't have checked exceptions, and Gradle by default does not print the exception type, it's not that critical which exception is thrown. In build scripts, GradleException is often used, but a Groovy assertion also seems reasonable (depending on the circumstances and audience). What's important is to provide a clear message. Adding a cause (if available) helps for debugging (--stacktrace).
Gradle provides dedicated exception types StopExecutionException/StopActionException for stopping the current task/task action but continuing the build.
Another option if you don't have any desire to be able to catch the exception later on is to call the ant fail task. It's slightly easier to read in my opinion and you can give a nice message to the user without use of --stacktrace.
task (tarball, dependsOn: warAdmin) << {
ant.fail('The sky is falling!!')
}
Gives you a message like:
* What went wrong:
Execution failed for task ':tarball'.
> The sky is falling!!
Probably you can catch this (perhaps it throws ant's BuildException?) but if that's a goal then I wouldn't use ant.fail. I'd just make it easy to see what exception to catch by throwing standard gradle exception as tim_yates suggested.
Throwing a simple GradleException works in stopping the build script. This works great for
checking required environment setup.
GradleException('your message, why the script is stopped.')
Example:
if(null == System.getenv()['GRADLE_USER_HOME']) {
throw new GradleException('Required GRADLE_USER_HOME environment variable not set.')
}
Here is a code fragment that tries to emulate how the Gradle javac task throws errors:
task myCommand(type:Exec) {
... normal task setup ....
ignoreExitValue true
standardOutput = new ByteArrayOutputStream()
ext.output = { standardOutput.toString() }
doLast {
if (execResult.exitValue) {
logger.error(output())
throw new TaskExecutionException( it,
new Exception( "Command '${commandLine.join(' ')}' failed; "
+ "see task output for details." )
)
}
}
}
When the command returns 0 there is no output. Any other value will print the standardOutput and halt the build.
NOTE: If your command writes to errorOutput as well, you may need to include that in the error log.