Getting following exception at random positions.
The runtime has encountered a fatal error. The address of the error
was at 0x65c08447, on thread 0x14d8. The error code is 0xc0000005.
This error may be a bug in the CLR or in the unsafe or non-verifiable
portions of user code. Common sources of this bug include user
marshaling errors for COM-interop or PInvoke, which may corrupt the
stack.
This module is worked fine yesterday but giving this exception today. i just changed debug configuration to x86. Yesterday it was AnyCPU. But i'm using sqlite and it reports following warning when configuration was AnyCPU.
Warning :- There was a mismatch between the processor architecture of
the project being built "MSIL" and the processor architecture of the
reference "System.Data.SQLite, Version=1.0.66.0, Culture=neutral,
PublicKeyToken=db937bc2d44ff139, processorArchitecture=x86", "x86".
This mismatch may cause runtime failures. Please consider changing the
targeted processor architecture of your project through the
Configuration Manager so as to align the processor architectures
between your project and references, or take a dependency on
references with a processor architecture that matches the targeted
processor architecture of your project.
I'm using unmanaged code from How do I get common file type icons in C#?. Also i'm using objectlistview.
All the code except this is just for accessing database.
my machine has windows 7 x64 ultimate.
Error starting to come up in search functionality of my application
Related
My application randomly crashes on my target machines with an .net failure. In mscorelib.dll there seems to be a System.InvalidCastException.
The error occures in:
System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(System.Object, Boolean)
and the reason is:
Unable to cast object of type 'System.Threading.ManualResetEvent' to type 'System.Threading._ThreadPoolWaitOrTimerCallback'.`
The Application runs multiple times on the target machine (win7 x64).
The Application is a x86 application.
There have never been issues before I was forced to compile the Application to the .net 4.6+ target framework. But I need to go up to at least 4.6 due to other dependencies now.
I thought it could be a issue with garbage collection and set <gcConcurrent enabled="false"/>. But this did not help.
I tried to debug the miniDumps with WinDbg. But I was not successful to find a way to track the Issue down to a specific line of code or a method in my code. I don't think it is a .net issue, but I have no clue how to find the corresponding line in my code.
Edit on request:
Former .net target framework: 4.5.1
The application crashes randomly, could be after more than 24h
I'm not able to figure out in which part of my code the application crashes
The same application runs independent parallel on the same machine. Sometimes randomly one or two instances crash.
When I debug ASP.NET MVC application, KeyVaultClient throws randomly exception:
Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has encountered a fatal error. The address of the error was at 0x59eab403, on thread 0x6098. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.'
I use:
nuget Microsoft.Azure.KeyVault 3.0.3
Visual Studio 2019 Professional 16.1.4
Microsoft.AspNet.WebApi 5.2.3
don't have Managed Compatibility Mode
I got familiar with this question and nothing helpful happens.
Edit
After enabling Managed Compatibility Mode I get slightly different error:
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'C:\Program Files (x86)\IIS Express\iisexpress.exe'.
Additional Information: The runtime has encountered a fatal error. The address of the error was at 0x6c0db403, on thread 0x54a8. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
occurred
From https://devblogs.microsoft.com/devops/switching-to-managed-compatibility-mode-in-visual-studio-2013/
New managed debug engine that provides us the ability to more rapidly add new features compared to the older implementation. This can be seen by the number of features introduced in Visual Studio 2013 after only a single year including Managed Return Values, .NET 64-bit Edit and Continue, Async Callstacks Enhancements, and Improved Tasks Window to name a few. Unfortunately, there are still a couple scenarios that are not supported yet with the new debug engine, so in these cases you will have to switch back to the legacy engine.
Error which you are getting is because of the issue which is not supported by new debug engine.
Please try below setting and see if you still get the same error.
To switch back to the legacy debug engine globally, select Tools/ Options
then check Use Managed Compatibility Mode on the Debugging / General tab.
The global option will force the legacy engine to be used for any launch or attach.
Hope it helps.
I have developed an addin for word in vs2010.It's working cool in 32 bit version of office, but its not working on 64bit version of office .Searched a lot and found that
For 64-bit Root\Software\Microsoft\Office\application name\Addins\add-in ID
For 32-bit Root\Software\Wow6432Node\Microsoft\Office\application name\Addins\add-in ID
registry information path's.I tried register the information for 64bit.Even too its not working in 64 bit of office. In 64 bit office my addin was displaying under InActive Application Add-Ins.I even tried enabling it.
How to develop and deploy an addin for 64 bit of office..?
and am getting the following error ..!!
Could not load file or assembly 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
************** Exception Text **************
System.BadImageFormatException: Could not load file or assembly 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at MyWord.ThisAddIn.ThisAddIn_Startup(Object sender, EventArgs e)
at MyWord.ThisAddIn.FinishInitialization()
at
Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.ExecutePhase(ExecutionPhases
executionPhases) at
Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.Microsoft.VisualStudio.Tools.Office.Runtime.Interop.IExecuteCustomization2.ExecuteEntryPoints()
WRN: Assembly binding logging is turned OFF. To enable assembly bind
failure logging, set the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There
is some performance penalty associated with assembly bind failure
logging. To turn this feature off, remove the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog].
An attempt was made to load a program with an incorrect format
In 99% of the cases, that just means one thing when this exception is raised in a 64-bit program. The "incorrect format" is a DLL that contains 32-bit code. That cannot work, a 64-bit program can only load 64-bit DLLs.
If you used C# to write that add-in then it is a very simple fix. Right-click the project in the Solution Explorer window, Properties, Build tab. Set the "Platform target" to AnyCPU. Untick the "Prefer 32-bit" checkbox if you see it (VS2012 and up). Repeat this for the Release configuration.
Other possible explanations for this, the unusual cases:
Not having the 64-bit version of the .NET Framework installed
Writing code in the C++/CLI language, you have to build the x64 version
Having a dependency on a 32-bit unmanaged DLL
Accidentally loading the wrong DLL
You'll need SysInternals' Process Monitor to chase these kind of mishaps down. The trace shows you what DLLs the Office program is looking for and in which directories it looked for the DLL. It will be a big trace, work from the bottom of the trace backwards.
Take a look at the Deploying an Office Solution by Using Windows Installer article in MSDN which describes all the required steps in depth. It states the following:
32-bit
HKEY_LOCAL_MACHINE\SOFTWARE(32-Bit)\Microsoft\Office\Excel\Addins\SampleCompany.ExcelAddIn
64-bit
HKEY_LOCAL_MACHINE\SOFTWARE(32-Bit)\Microsoft\Office\Excel\Addins\SampleCompany.ExcelAddIn
HKEY_LOCAL_MACHINE\SOFTWARE(64-Bit)\Microsoft\Office\Excel\Addins\SampleCompany.ExcelAddIn
An installer for 64-bit Windows requires two registry paths because it’s possible for users to run 32-bit and 64-bit versions of Office on a computer that runs 64-bit Windows.
But you may detect (in the custom actions) the bitness of MS Office installed and create keys in the proper hive.
I've recently been tasked with adding a report to an older WPF application. Part of the process involved adding ActiveReports to the solution in question.
After getting the report implemented and tested on my local machine, it came time to commit it up to our Dev/Test build environments. Everything went fine, until I attempted to run the application on a machine that did not have ActiveReports installed and licensed on it - I got the "Viewer needs to be licensed error window."
Here's where things get confusing, though. It should be working.
For starters, I'm running ActiveReports 8.0.133.0.
The contents of my licenses.licx file are:
GrapeCity.ActiveReports.SectionReport, GrapeCity.ActiveReports.v8, Version=8.0.133.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff
I've generated a satellite licensing DLL for the WPF project's executable, and ensured that it's referenced and set to Copy Local = true. (I've already dealt with this in the past.)
Even though it's not a web project, for safety's sake, I used the WebKey Generator and added an Active Report 8 Developer key to the app.config file.
It gets more interesting, though. When I add the following lines to my licenses.licx file, as the error window I get above suggests I should do:
GrapeCity.ActiveReports.Viewer.Win.Viewer, GrapeCity.ActiveReports.Viewer.Win.v8, Version=8.0.133.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff
GrapeCity.ActiveReports.Viewer.Wpf.Viewer, GrapeCity.ActiveReports.Viewer.Wpf.v8, Version=8.0.133.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff
When I try to simply build the project in Dev, the build fails with the following message:
[10:29:34] [exec] (CompileLicxFiles target) ->
[10:29:34] [exec] Properties\licenses.licx(2): error LC0004: Exception occurred creating type 'GrapeCity.ActiveReports.Viewer.Win.Viewer, GrapeCity.ActiveReports.Viewer.Win.v8, Version=8.0.133.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff' System.ComponentModel.LicenseException: License cannot be confirmed. Error code: 01-001 [C:\CheckoutDirectory\Project\[(0) BUILD]\UI\UI.csproj]
[10:29:34] [exec] Properties\licenses.licx(3): error LC0004: Exception occurred creating type 'GrapeCity.ActiveReports.Viewer.Wpf.Viewer, GrapeCity.ActiveReports.Viewer.Wpf.v8, Version=8.0.133.0, Culture=neutral, PublicKeyToken=cc4967777c49a3ff' System.ComponentModel.LicenseException: License cannot be confirmed. Error code: 01-001 [C:\CheckoutDirectory\Project\[(0) BUILD]\UI\UI.csproj]
For those who don't want to scroll:
System.ComponentModel.LicenseException: License cannot be confirmed. Error code: 01-001
The end result is a sort of Morton's Fork of badness. Either I can build the app, but I can't run the report (which, is sort of the point of me making these changes), or I simply can't build the app at all.
Question: What can I do to get the report viewer to run without a license exception and keep the application building? I should also note, I'm on a short deadline with this!
I was correct to add the Win and WPF viewer lines; it turns out the answer was to upgrade the Build server with Active Reports 8. From there, everything went swimmingly.
TL;DR - Upgrade everything that needs to be upgraded!
I have a language compiler that I've just updated to target .NET 4.0 and the metadata generator for framework assemblies now fails on System.Data.dll, while all others work fine (mscorlib, System, etc.)
The metadata generator simply loads assemblies, reflects over all the types and memberinfo and generates a stub class for the language.
I'm using Assembly.Load() and/or Assembly.ReflectionOnlyLoad()
Could not load file or assembly 'file:///c:\windows\Microsoft.NET\framework\v4.0.30319\System.Data.dll'
or one of its dependencies. An attempt was made to load a program with
an incorrect format.
It is built for "AnyCPU". I'm running Windows 7/x64 with .NET 4.5 update installed.
If you use corflags tool to analyze the assemblies, you should see that ILONLY: 0 for System.Data.dll while the others (mscorlib, System) ILONLY: 1. More information regarding ILONLY can be found at here.
Thus, the assemblies were built differently and you should not expect reflection to work for all. System.Data.dll seems to be a mixed-mode assembly, which is always bitness dependent.
If you cannot run your app as 32 bit so as to load the 32 bit assemblies, you might consider Mono.Cecil as #xmojmr said, as it supports reading mixed-mode assemblies.