c#, when running compiled app on other systems..., ScintillaNET signature Error? - c#

I am having problems when I distribute software I developed, the compiled .exe runs fine on my system but when parsed to others it displays the below error, on both 32 bit and 64 bit systems.
I have tried many compile options, including obfuscating, building for any CPU, building for 64bit and 32, I also tried, building on other systems, all .dlls are supplied in the package, i even tired merging the .dlls that I could without breaking license agreements etc.
Even registered all .dlls on the other system.
Any ideas?
I did some googling, but as a last resort i have had to ask here, Knowing my luck it will be something obvious, The error leads me to believe the dlls are not there but they are...
Here is the error below:
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: testtool.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 4e1ec8bf Problem
Signature 04: ScintillaNet
Problem Signature 05: 2.2.3581.19319
Problem Signature 06: 4adf566e
Problem Signature 07: 66e Problem
Signature 08: 5c
Problem Signature 09: System.IO.FileNotFoundException
OS Version: 6.1.7600.2.0.0.272.7
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
...Runs fine on the system I compile it on.
The above leads me to think the dll's are not there... but they are.
Thanks kindly,
Scott

If you have a .NET app that crashes for no apparent reason on another system, and the error report hints at the fact that an exception is thrown (like System.IO.FileNotFoundException), you should add a handler for unhandled exceptions (AppDomain.CurrentDomain.UnhandledException) and then just output the whole exception (e.ExceptionObject.ToString()) with a message box. The stack trace should give some more insight into what is happening (you can also make use of the other Exception properties). A debug build with PDB files will additionally provide line numbers.
See http://www.csharp-examples.net/catching-unhandled-exceptions/
It's important to add this event handler at startup of your app, before the exception has a chance to happen. Using tools like Windbg is usually overkill for managed exceptions.

Related

Crashing deployed app on XamlParse

I have created a ClickOnce Application Deployment Manifest from my WPF application but when I try to install it, this crashes and I get the following error log:
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: phynix.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 54b90fb3
Problem Signature 04: mscorlib
Problem Signature 05: 4.0.30319.17929
Problem Signature 06: 4ffa561c
Problem Signature 07: 43c4
Problem Signature 08: 105
Problem Signature 09: System.Windows.Markup.XamlParse
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1031
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
Someone knows what is the problem??
The XamlParse exception means the XAML can't be read or the code generated from it can't be executed correctly.
Usually this is:
An image file that isn't included as resource in the project, or in a location that isn't available on the deployment machine;
Missing referenced assemblies and/or their dependencies.
Try hooking up an UnhandledException event in WPF, and add the event hookup in your app.xaml in order to avoid the above exception.
Reference: How can I get useful WPF .NET error information from a user's machine?

C# WPF program runs in debug but not release without debugging

Trying to test a small program in release mode without debugging. Program runs fine in debug mode, and fine in release mode with debugging. When I try to run in release with no debugging the following happens.
*Note: I've tried multiple configuration modes. For configurations other than x86 and platform = x86 gives me a mismatch processor architecture error.
Project being built = MSIL | Reference architecture of ChilkatDotNet45 is x86
I've run in many different configs.
Is this a project reference being the wrong architecture type or something else?
Do I just need to try to find a different version of MySql.Data.CF library?
Anyways, here's what I have...if you need more request it:
An unhandled exception of type 'System.IO.FileLoadException' occurred in CWPart2 - WPF.exe
Additional information: Could not load file or assembly 'MySql.Data.CF, Version=6.9.5.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d, Retargetable=Yes' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: cwpart2 - wpf.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 547befe6
Problem Signature 04: CWPart2 - WPF
Problem Signature 05: 1.0.0.0
Problem Signature 06: 547befe6
Problem Signature 07: 9f
Problem Signature 08: ed
Problem Signature 09: System.IO.FileLoadException
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Make sure you have a copy of the database files in the Release folder

WPF - Program crashes

WPF application I wrote runs fine on my PC but on my friend's (same as mine Win 7 x64) it crashes. I tried to compile it either to x86 or x64 but problem still persists. I also sent him test app with simple button and message to see if it's lack of .net framework problem but it runs with no problems. My app uses MSSQL and on WPF part binding and various templates which were not included in test case. What is wrong with it?
I include error report(sorry for possibly bad translation it was in different language):
Problem signature:
Problem event name: CLR20r3
Problem signature: 01: surfmanagertake2.exe
Problem signature: 02: 1.0.0.0
Problem signature: 03: 53b3b026
Problem signature: 04: PresentationFramework
Problem signature: 05: 4.0.30319.18408
Problem signature: 06: 52312f13
Problem signature: 07: 7fe8
Problem signature: 08: ee
Problem signature: 09: System.Windows.Markup.XamlParse
Operating system version: 6.1.7601.2.1.0.768.3
Regional settings ID: 1045
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I've seen similar problems before, where the app works perfectly fine on some machines and crashes\slow on others which appear to be the same physical\OS spec.
I tracked down the issue to differing versions of core assemblies used by WPF - PresentationCore.dll, PresentationFramework.dll etc.
The easiest way to see all the managed references (.Net assemblies) a process is using a tool like Process Explorer or ProcDump (both from sysinternals).
These should allow you to take a full dump which can then be openned in Visual Studio and show a list of the loaded assemblies and their versions. If the version numbers of the core WPF assemblies are different then I suggest one of the machines has a Hotfix the other doesn't.
http://blogs.msdn.com/b/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx

WPF : Error on Initialize component (Test Machine)

I created a software which has a Administrator and user login which on successful login takes it to their respective XAML pages. This works fine from code and installer on the machine where i created the software.
Now on deploying this on a test machine the app crashes in the Initialize component of the Admin page (Identiifed with debug mesages). The error report gives me this
Problem Event Name: CLR20r3
Problem Signature 01: gage selector.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 52cd1461
Problem Signature 04: mscorlib
Problem Signature 05: 4.0.0.0
Problem Signature 06: 4e181ae3
Problem Signature 07: 3fd1
Problem Signature 08: 105
Problem Signature 09: System.Windows.Markup.XamlParse
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
I am not able to figure out what is happening especially so since Operator xaml page loads fine in the test machine as well. Please guide on how to proceed in this case.
AS Patrick Hoffman pointed out this is a minor issue when some paths are inaccessible on XAML page. In my case i had not updated the dynamic path for the logo on Admin page while i had done for other pages. Changing it to dynamic path fixed the issue.

Create a Installation setup for a windows form application in VS2010 using InstallShield limited edition

I have succeeded in creating the setup.exe and it runs to completion.
But on clicking the icon created I get an error message box stating:
"Application has stopped working" with the 3 options, Close, Debug, check for online solutions.
The details of the problem are:
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: zed axis.exe
Problem Signature 02: 10.0.4925.7882
Problem Signature 03: 51cadd13
Problem Signature 04: Zed Axis
Problem Signature 05: 10.0.4925.7882
Problem Signature 06: 51cadd13
Problem Signature 07: 4d69
Problem Signature 08: b
Problem Signature 09: System.IO.FileNotFoundException
OS Version: 6.2.9200.2.0.0.256.72
Locale ID: 1033
My guess was that it cant find the .exe file. But I don't know where I am going wrong could you help me resolve this.
FWIW, some people think that it's InstallShield (or similar tools) job to autodetect your dependencies and author them for you. In fact, InstallShield does have some functionality to achieve this. But IMO it's a hopeless attempt. For any programming endeavor step 1 is to determine the requirements and step 2 is to implement them.
Many will argue that the point of spending $ on InstallShield is to automate this. I couldn't disagree more. Automation is nice but at the end of the day it's my job to understand my deployment requirements and validate that they are implemented correctly.
You need to profile your application to understand what file is missing, add it to your installer and rinse and repeat. This could simply mean looking at the code, or using ILDASM or .NET Reflector or even ProcessExplorer to determine the missing component.

Categories