Changing language in UWP making app to crash - c#

I have a weird issue that I cannot solve.
I am using the following code to change my app language:
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = codeOfLanguage;
The codeOfLanguage variable is string and the error occurres when I am trying to change the language to "bg-BG" (same if I try "bg"). What happens is I get a Just-in-time debugger window in my face (despite I am currently debugging from VS2015) and the app crashes. I cannot catch the Exception from Studio.
I only found the following clue in the Application eventlog:
Faulting application name: {myAppName}, version: 1.0.0.0, time stamp: 0x5a3d1876
Faulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2bcf
Exception code: 0xc0000002
Fault offset: 0x000daa12
Faulting process id: 0x3ca4
Faulting application start time: 0x01d37b3249d8cc91
Faulting application path: {myAppPath}
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 56827555-577b-4276-8ef0-217065912b46
Faulting package full name: {myPackageName}
Faulting package-relative application ID: App
After restarting the app the language is changed to "bg-BG" and resources are loaded accordingly.
When I am changing the language back to English ("en-GB") the issue does not occur.
Does anybody have any idea how to move forward with this? Where could I find more info on the issue and the solution?
Thanks,
Gabor

Related

Is it possible to trap a ucrtbase.dll fault in Visual Studio debugger

I need to be able to trap a ucrtbase.dll fault in our application, can't seem to find any good way to do it. Is it possible to capture this in the VS debugger to see where we are on the stack when the fault occurs?
We see issues more often these days where our application goes unresponsive and shuts down with nothing in our logs. We do see the following in the Eventlog:
Faulting application name: ******************************
Faulting module name: ucrtbase.dll, version: 10.0.19041.789, time stamp: 0x2bd748bf
Exception code: 0xc0000409
Fault offset: 0x000000000007286e
Faulting process id: 0x3754
Faulting application start time: 0x01d8faaaf85feff3
Faulting application path: ********************************
Faulting module path: C:\WINDOWS\System32\ucrtbase.dll
Report Id: b56fdb9c-6b0a-4186-9d0e-73570b51c0d2
Faulting package full name:
Faulting package-relative application ID:
Event log shows there is a WER report, with no usable data...
If this is not the proper place to address this query, please advise on the proper forum to post as a ucrtbase Windows issue for tracking.
Additional:
I found the following report on ucrtbase.dll with version: 10.0.19041.789: but we are not running WSL -> more likely the problem is in ucrtbase.dll or possibly hardware than an application/platform issue.
=-=-= Original: https://github.com/microsoft/WSL/issues/8256
Please advise.
Thanks much,
-Timothy
tried capturing in debugger for triage, no luck.

How to diagnose fault in crashing UWP app

I have a UWP application which runs fine from Visual Studio with the debugger attached. If I run the app standalone, from the start menu - which is the app that Visual Studio has deployed - it will start, but crash when I invoke one of the functions in the app.
UWP provides absolutely no information - the window disappears and I get the following in the Event Viewer:
Faulting application name: MyApp.Uwp.exe, version: 1.0.0.0, time stamp: 0x5c889173
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.18362.207, time stamp: 0x36bacadb
Exception code: 0xc000027b
Fault offset: 0x0086b264
Faulting process id: 0x27f4
Faulting application start time: 0x01d53db7eaba0778
Faulting application path: C:\src\MyApp\bin\x86\Debug\AppX\MyApp.Uwp.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 009e5859-3f05-4790-8072-37af666acb7e
Faulting package full name: 59640b3f-2209-4686-8f9a-9f8748b9753c_1.0.0.0_x86__9617mk99wz2v0
Faulting package-relative application ID: App
If I start the app via the Start menu, then attach the VS debugger, it doesn't crash.
How can I get a stack trace and work out what is going wrong here?
I want to know if it's possible to get a stack trace or any information out of a crashed UWP app.
You could use HockeyApp to capture the exception call stack, exception message, exception type name, file name and line number which caused a crash in the app. For more detail please refer this document.
Please note: In order to symbolicate crashes for .NET UWP applications you need to upload symbol (*.pdb) files

Stackoverflow exception (0xc00000fd) on Windows Server 2016

I made winforms app which running fine on my win8, but on windows server 2016 it crashes before window appears. I found this in Event Viewer:
Faulting application name: MyApp.exe, version: 1.0.0.0, time stamp:
0x597b5764 Faulting module name: clr.dll, version: 4.6.1648.0, time
stamp: 0x58e3fbcf Exception code: 0xc00000fd Fault offset: 0x0045068d
Faulting process id: 0x9078 ...
Maybe this will be helpfull: 32bits application using external dlls dynamicaly, but it crashes before using assembly.
Is anyone had similiar issue and solve this?
Help would be greatly appreciated!
Problem was LineShape object on Form, when I delete it everything is OK.

Faulting module name: KERNELBASE.dll

My application crashes without any application error logging, when I checked Event viewer I found below info. Can some explain why this would happen and how to prevent it?
Faulting application name: MyApplication.exe, version: 1.0.0.0, time
stamp: 0x5964fac7 Faulting module name: KERNELBASE.dll, version:
6.1.7601.23807, time stamp: 0x5915f98e Exception code: 0xe0434352 Fault offset: 0x0000c54f Faulting process id:
0x1494 Faulting application start time: 0x01d300cbc9034bc0
Faulting application path: Path of MyApplication.exe Faulting
module path: C:\Windows\syswow64\KERNELBASE.dll Report Id:
b1f21346-6cbf-11e7-bb68-005056ad2203
I was building a WPF application in C# and packaging it using the MSIX packager/installer. Everything was fine until I updated Visual Studio to 16.10.2. Then something strange started to happen. The code would run perfectly in Debug and Release configuration but when I installed the application from MSIX it failed to run.
There were no coding errors.
The Event Log gave this error..
Faulting application name: [app name here], version: [app version here], time stamp: 0x609308e7
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1023, time stamp: 0x924f9cdb
Exception code: 0xe0434352
Fault offset: 0x0000000000034b89
Faulting process ID: 0xf3c
Faulting application start time: 0x01d7659e116b2c8c
I tried almost everything but nothing seem to fix it. Then I noticed the the 'obj' folder had become huge, so I deleted it and low and behold that fixed the problem.
I know this is old, but thought I'd post Luke's advice as an answer since it solved my problem.
As Luke mentioned in a comment above, the issue for me was an unhandled exception that was happening on startup. Once I wrapped the startup code in a try catch, I found the problem which was totally a bug in my app, nothing to do with kernalbase.dll or any other external dependency or reference.

Windows Service keep crashing with Faulting Module SHLWAPI.dll

I have a Windows Service running in "Local System account" context.
I can start the service successfully, but after a few minutes it crashes. I get following error in the event log
What could be the possible reason, and how to fix this issue?
Faulting application name: MyWindowsService.exe, version: 1.0.0.2993, time stamp: 0x554085eb
Faulting module name: SHLWAPI.dll, version: 6.3.9600.16384, time stamp: 0x521574db
Exception code: 0xc00000fd
Fault offset: 0x00005d66
Faulting process id: 0x14d4
Faulting application start time: 0x01d0830a94202cb3
Faulting application path: C:\Program Files\MyProject\Etswap Workflow Polling Service\MyWindowsService.exe
Faulting module path: C:\Windows\SYSTEM32\SHLWAPI.dll
Report Id: ff232358-eefe-11e4-94ea-08002787efe4
Faulting package full name:
Faulting package-relative application ID:
yes, it was a bug in the application only.
it was a rare scenario which was going into a deadlock situation.
Fixed

Categories

Resources