I have two computers. Both work under Windows 7 Embedded and have same version of .Net 4.0 framework installed.
My WinForms application works with no issues on one of them but fails at start-up with BEX in clr.dll on another.
Problem Event Name: BEX
Application Name: Myapplication.exe
Application Timestamp: 5669ec33
Fault Module Name: clr.dll
Fault Module Version: 4.0.30319.526
Fault Module Timestamp: 4eb3b6b1
Exception Offset: 002b65ec
Exception Code: c0000409
Exception Data: 00000000
OS Version: 6.1.7601.2.1.0.320.65
Locale ID: 1033
Additional Information 1: a835
Additional Information 2: a835052745ddb3bce091e0cd181de7e7
Additional Information 3: 7cb8
Additional Information 4: 7cb8eec426d05584b36071af9d74719d
What is very "strange"
I was able to find two things in my application that somehow have impact or provoke this problem.
First I found exact line of code.. I have few buttons that I manually create manually on UI thread. And if I remove next line my application starts.
btn.Font = new Font("Tahoma", 9, FontStyle.Bold, GraphicsUnit.Point, 0);
Second I noticed that if I use my debug logger which uses StackFrame to find out where log message is coming form, Application will crash with the same error in CLR but at some other place. Not at the line I mentioned above.
My two computers have different RAM. 2GB and 1GB. Application fails on the second one with 1GB of memory. But application iself uses 30 MB and system has ~350 MB of free memory. Could memory be a reason ?
My research for the most part referred me to different hot-fixes issued by Microsoft. I tried them but nothing helped. I also tried to install .Net v4.5 but with the same negative result.
Where else I can start looking for the problem ?
... And yes, this problem does not show up when running application with attached debugger.
Update
I just realised that "Exception Code: c0000409" means STATUS_STACK_BUFFER_OVERRUN. This brings some sense to strange application behaviour that I have but still not clear why it works on one computer but does not work on another.
Solution finally found
My application uses third party C# library which is actually a wrapper on top of calls to other native library. I decompiled library and realised that calling convention is set to CallingConvention.Cdecl but as I see from Dependency Walker application, all methods in native library has CallingConvention.StdCall
After changing calling convention and recompiling the library issue disappeared.
Related
I'm trying to implement Brother b-Pac printing library for label printing devices into my web application. I need to create/load the label template on server and print from the client's machine over a browser.
My code is totally working on my development environment. It only occurs on the published version. It's an access denied error thrown when the COM object got called by the app. I suspect there's an inner exception I couldn't reach.
The event got logged as follows:
Faulting application name: w3wp.exe, version: 8.5.9600.16384
Faulting module name: bpac.dll, version: 3.2.0.20
Exception code: 0xc0000005
Fault offset: 0x0010beea
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Program Files (x86)\Common Files\Brother\b-PAC\bpac.dll
I also used DebugDiag on the dump file and here's the report. Though it says here debugger couldn't locate debug symbols for bpac.dll, so it may be incomplete (If it may help, I'd like to know where and how to get symbols for a 3rd party DLL)
Application is a multilayer ASP.NET MVC app targeting the .NET Framework 4.6.1, running on a virtual machine with Windows Server 2012 R2 (x64) and IIS 8. (If it matters the project is derived from this template)
I searched about the issue and tried the following solutions:
Give read/write permissions of wwwroot and DLL's own folder to the IIS APPPOOL/user of the faulting w3wp.exe.
Give same permissions to IIS_IUSRS, NETWORK, NETWORK SERVICE users.
Impersonate Administrator user.
Uninstall/install 32bit/64bit versions of the b-Pac SDK.
Change bitness of my ASP app and all projects within to x86/x64.
Enable 32bit on the Application Pool.
Patch the Windows for July 2018 update issue
Setting Anonymous Authentication, App pool identity etc. all to the default pool user.
Loading the DLL dynamically. (not sure if I did this correctly though)
The COM object I'm trying to initialize is bpac.Document. Interface is IDocument and the concrete class is DocumentClass. I wasn't familiar with any of these concepts before. And I'm still struggling to understand but I tried all of these following lines for initialization:
Document label = new Document();
DocumentClass label = new DocumentClass(); //embed interop types: false
IDocument label = new Document();
After that, I'm using label object to open a template and etc. But as soon as the application hits any of the above lines it crashes the server and restarts the app.
Incidentally, the DLL file is referenced as a COM library in my WebService (App) project (not in the Web project). So it doesn't get copied on bin folder (I guess that's the correct behaviour?). Tried changing isolation/interop settings but I'm not sure if those are related to the issue at hand.
I read things about Registering COM objects into GAC and Marshalling for Remote Access but I couldn't grasp how to apply these properly. Thing is, the official documentation doesn't say anything about this. And there isn't a single example for using b-Pac library on a modern C# ASP.NET setting (only a little on VB ~eww~).
I'm a developer, not a DBA so I'm not too confident with tweaking the server's settings. But for this issue alone, I modified too many things too many times.
So, the problem was about the app id permissions all along. I changed the Application Pool's identity to LocalSystem and now it works as expected.
Still, I'm not sure what kind of security flaws this change would cause in the future. I posted this link to the vendor's technical staff. But they didn't give me an answer yet.
When I let run all tests (ca. 800 tests) in my solution, after some time a popup window with error is shown that vstest.executionengine.x86.exe has stopped working.
Some Examples of problem details, that I get are here:
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: vstest.executionengine.x86.exe
Problem Signature 02: 14.0.23107.0
Problem Signature 03: 559b7b6c
Problem Signature 04: mscorlib
Problem Signature 05: 4.6.1076.0
Problem Signature 06: 56d79fa2
Problem Signature 07: 0
Problem Signature 08: ffffffff
Problem Signature 09: System.StackOverflowException
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1051
Additional Information 1: 5cd2
Additional Information 2: 5cd2742c12da7dd4b1d5bf900186a452
Additional Information 3: 2fe2
Additional Information 4: 2fe276cacf1c00cd7a2aed7b27f5a5f9
Problem signature:
Problem Event Name: APPCRASH
Application Name: vstest.executionengine.x86.exe
Application Version: 14.0.23107.0
Application Timestamp: 559b7b6c
Fault Module Name: clr.dll
Fault Module Version: 4.6.1076.0
Fault Module Timestamp: 56d7a0ff
Exception Code: c00000fd
Exception Offset: 00003567
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1051
Additional Information 1: 0127
Additional Information 2: 01273c850b3b6fc6378d3f666887788e
Additional Information 3: 0786
Additional Information 4: 07866ddaac895bff9a7fa791fcdaa4a7
In VS output window I get:
------ Run test started ------
The active Test Run was aborted because the execution process exited unexpectedly. To investigate further, enable local crash dumps either at the machine level or for process vstest.executionengine.x86.exe. Go to more details: http://go.microsoft.com/fwlink/?linkid=232477
========== Run test finished: 0 run (0:03:55,0267906) ==========
When I tried to enable local crash dumps I found out that there is no such registry key so I haven't been able to do it.
I Located all test (22 tests) causing crash of vstest.---.exe, commented them and run all test again and without those "wrong" tests. Everything runs fine.
What can be wrong with those tests? They all are old tests which was working in past. How to locate a problem?
In my experience, StackoverFlowExeptions are very often caused by some recursive method call that never terminates. Try debugging one of those 22 test to find out if recursion is the issue.
There are multiple ways to find the cause of a StackOverflowException in a unit test.
Probably the easiest one is to run one of the 22 tests you've identified under the Visual Studio debugger. For this you select "Debug selected tests" in the context menu of VS Test Explorer. If the exception happens, VS will break and you will be able to look (very) deep into the call stack to find exactly the place where it begins to cycle in a method call loop.
There might be legitimate reasons for this loop (like recursive methods) or there might be a bug. In case of the former it's maybe possible (amongst many other possibilities) that some hierarchical data changed and therefore the unit tests now hit a limit when analyzing the hierarchy recursively.
If you cannot run the unit tests in the VS debugger then you have to get a memory dump of the crashing vstest.executionengine.x86.exe using Windows Task Manager.
For that you first wait until the window of the Windows Error Reporting (WER), that you mentioned in your question, pops up. Then you open Task Manager in the correct bitness - that is 32-bit in your case. That means if you have a 64-bit OS, you have to start C:\Windows\SysWOW64\taskmgr.exe. If you have a 32-bit OS you can run the normal one at C:\Windows\System32\taskmgr.exe.
Then you right click on the vstest.executionengine.x86.exe process and choose "Create Dump File". The resulting .dmp file can be loaded into VS or into WinDbg where the call stacks can be analyzed using the SOS extension.
For debugging a memory dump in VS you can read more about it here.
Regarding WinDbg you have to download it here, set up a few initial configuration settings mentioned here and then list the threads and their call stacks using the commands stated here.
Now you should pretty easily get to the root cause of your problems.
I'm working on a Windows 10 Store application where I'm using Raygun.io (5.2.0). We released the app couple of times (latest in mid December) I see in Rayguns web interface the logs coming from previous versions. While testing the app now before publishing next version I found out that Raygun is not working anymore (= crashing) when sending exceptions if app is build using .NET native toolchain.
I can reproduce this in a simple UWP test app:
public sealed partial class MainPage : Page
{
//private readonly RaygunClient _raygunClient;
public MainPage()
{
InitializeComponent();
RaygunClient.Attach("<app_key>");
//_raygunClient = new RaygunClient("<app_key>");
}
private async void OnClick(object sender, RoutedEventArgs e)
{
try
{
// this is crashing the app when project is build using .NET native toolchain
// it is not even throwing exception
//await _raygunClient.SendAsync(new InvalidOperationException("Raygun Test"));
await RaygunClient.Current.SendAsync(new InvalidOperationException("Raygun Test")); // (1)
Status.Text = "Ok";
}
catch (Exception exception) // (2)
{
Status.Text = $"Failed with {exception.Message}";
}
}
}
Checking https://github.com/MindscapeHQ/raygun4net supported platforms/frameworks, it doesn't seem to support explicitly UWP.
UPDATE: The application is killed after line (1), there is no exception caugh at (2)
In Event View I can see:
Faulting application name: rayguntest.exe, version: 1.0.0.0, time stamp: 0x56a0edc9
Faulting module name: mrt100_app.dll, version: 1.0.23406.0, time stamp: 0x561408ce
Exception code: 0x80000003
Fault offset: 0x000000000000a0ad
Faulting process id: 0x305c
Faulting application start time: 0x01d1545a0fea5649
Faulting application path: C:\Projects\rayguntest\rayguntest\bin\x64\Release\AppX\rayguntest.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.NET.Native.Runtime.1.1_1.1.23406.0_x64__8wekyb3d8bbwe\mrt100_app.dll
Report Id: 52bbeeb5-97c6-4814-b5dc-51ee6c3fa9bd
Faulting package full name: 6ca59c51-ed22-482b-acf6-12d241079f4d_1.0.0.0_x64__1d8r4kqm7qz2y
Faulting package-relative application ID: App
We have completed our investigation and this is indeed a bug inside of .NET Native. The issue is that for some cases we didn’t properly handle all cases involving invalid casts. Specifically casting Arrays to a generic type with more than one generic parameter. You can see the spots in Raygun where we are going to run into issues by examining SimpleJson.SerializeValue:
https://github.com/MindscapeHQ/raygun4net/blob/67c4bb9fd660afb91d62e9333d75a36a85ee5d4f/Mindscape.Raygun4Net/SimpleJson.cs#L1016
One workaround would be to avoid having this code path serialize an Array in the first place. Another, would be to patch RayGun to check for the array case first and avoid all of the other guesswork it’s trying to do.
The reason you don't see an exception is because the runtime is pretty defensive about the various asserts and fall troughs so it calls the OS FailFast in these cases.
Hope that helps.
Excerpt from Microsoft:
If the necessary metadata or implementation code is absent at runtime,
the .NET Native runtime throws an exception. You can prevent these
exceptions, and ensure that the .NET Native tool chain includes the
required metadata and implementation code, by using a runtime directives file,
an XML file that designates the program elements
whose metadata or implementation code must be available at runtime and
assigns a runtime policy to them.
From Microsoft on .NET Native and Compilation:
The resulting app that is produced by the .NET Native tool chain is
written to a directory named ilc.out in the Debug or Release directory
of your project directory. It consists of the following files:
•appName.exe, a stub executable that simply transfers control to a
special Main export in appName.dll.
•appName.dll, a Windows dynamic link library that contains all your
application code, as well as code from the .NET Framework Class
Library and any third-party libraries that you have a dependency on.
It also contains support code, such as the code necessary to
interoperate with Windows and to serialize objects in your app.
•mrt100_app.dll, a refactored runtime that provides runtime services
such as garbage collection.
I have an application written in C#. This application is locking by windows, return something like: "The xxx application has stopped working".
Is it possible to get the reason for this crash? I tried using try{} catch{} throughout the application without success. It works on my computer, but not on my friend's computer.
Both computers have same configuration:
Windows seven 7 ultimate 32 bits
Processor:2.13ghz
memory ram: 2gb
UPDATE
Well, in the event log of computer of my friend I found some details of the crash:
Faulting application name: xxxx.exe, version: 1.0.0.0,time stamp:0x4eb5e63a
Fault Module Name:KERNELBASE.dll, version: 6.1.7600.16850, time stamp:0x4e21132b
Exception Code:0xe0434352
Identification of the process that failed: 0x26c
Start time of the faulting application: ...
Faulting application path: ... \xxx.exe
Path F module failures: C:\Windows\system32\KERNELBASE.dll
Report ID: xxxxx-yyyy-dddd-dddd-aaaaaa
UPDATE 2
Finally,I found the function that is causing the exception.
handling the function with try {} catch (Exception Err) {} I found some details of exception:
Err.Message:The device is not ready
Err.Source: mscorlib
how can I fix it?
"Works on my machine" is a very common problem with a myriad of causes. Generally the reason is that something is different between the two machines. Some easy things to rule out:
is your friend's computer a development machine, with Visual Studio installed?
does your application rely on a particular path (for example, a D: drive), a database, a service, a COM component, or something else that an install package should be including?
has your friend configured UAC differently from you? Does one of you sign on as the account Administrator, while the other uses another account that is in the Administrators group?
did you test a debug version on your friend's machine? debug versions usually aren't redistributable
did you test version x of the exe and version y of some class library, forgetting that you made a change to one of them yesterday?
do you and your friend have different versions of IE, Office, or some other component that may be used by the app? Do you have different IE settings (eg proxies?)
are the two computers both completely caught up on updates and service packs?
is the application trying to access some hardware (microphone, web cam) that is not on your friend's machine or is importantly different between the two machines?
The literal answer to your question is yes, you can sign up for something called Windows Error Reporting and get the reports that the dialog says it is collecting. However I sincerely doubt that you want them. You should have all the information you need to find the error right where you are. Concentrate on what is different (even if you think it's irrelevant) between the two machines.
Most likely it is a missing dependency. Double check to make sure that your program is installing all of the Dll's that it needs. I have run into similar problems usually with an .ocx file not being properly registered or not present.
As far as your question goes try using the MDbg.exe file from the .Net Framework SDK or Visual Studio. Microsoft also has other debugging tools available.
I created a pretty simple c# application using visual studio 2010 on windows xp. It compiles, runs and debugs fine on my machine. I even built it for release and ran the .exe on my machine and another windows xp machine perfectly fine. When I send the release folder with the .exe file and they open it, nothing happens! No errors or anything, just blank!
.NET version 4 framework installed
It is a windows form application.
UPDATE: Details from OP's comments given to one of the answers below:
Hey everyone, thanks for the ideas. I
copied what I found on my friends
windows 7 machine event log and this
is what it said:
Application: ePrescribing.exe Framework Version: v4.0.30319
Description: The process was
terminated due to an unhandled
exception. Exception Info:
System.IO.FileNotFoundException Stack:
at
ePrescribing.frmApp.InitializeComponent()
at ePrescribing.frmApp..ctor() at
ePrescribing.Program.Main()
Faulting application name: ePrescribing.exe, version: 1.0.0.0,
time stamp: 0x4d61e693 Faulting module
name: KERNELBASE.dll, version:
6.1.7600.16385, time stamp: 0x4a5bdbdf Exception code: 0xe0434352 Fault
offset: 0x0000b727 Faulting process
id: 0xb38 Faulting application start
time: 0x01cbe1dbe6d4ba2d Faulting
application path:
C:\Users\Duane\Downloads\ePrescribing.exe
Faulting module path:
C:\Windows\syswow64\KERNELBASE.dll
Report Id:
266adc61-4dcf-11e0-8438-e0cb4e197cde –
Fault bucket , type 0 Event Name: CLR20r3 Response: Not available
Cab Id: 0 Problem signature: P1:
eprescribing.exe P2: 1.0.0.0 P3:
4d61e693 P4: ePrescribing P5: 1.0.0.0
P6: 4d61e693 P7: 28 P8: e P9:
System.IO.FileNotFoundException P10: –
I removed the only area where I
thought there would be a file load
(for the picturebox loading
profile.jpg) and still got the same
error. Any ideas?
First, you might try checking the Event Viewer for any relevant errors messages (as stated above).
Next, make sure they have .NET installed (as stated above).
Then, try adding an UnhandledExceptionEventHandler to your application and in that handler, try to at least write a simple log/text file containing the exception that caused your application to exit.
Make sure the latest .NET framework is installed.
Check .NET framework installed on win7 computer equal your application framework target.
Check in the process explorer that it's running but didn't show you anything.
Check event log for crash reports.
Try to add logging to your application in different places and add unhandled error handlers.
Additionly to other answers I would also check whether your app compiled against x86/x64 runtime
Have you included a manifest file?
Take a look at this.
Or this...
Are you accessing any folders via static paths instead of environment variables? That could cause issues between these versions of Windows.
You should check if all other third party assemblies can be found either in GAC or app folder
Referenced assembly may be missing from target computer. Please set Copy Local=True for all referenced library. This may solve your issue.