I had a problem in upgrading the Microsoft XML core for my application from msxml3.dll to msxml6.dll. I chnaged the vcproj, and the header file of mine to point to the msxml6 header and library file. I also changed the class id of msxml6 to create a document praser using CoCreateVariant() function.
During execution i found my application throws unexception handling and aborts. Then i debugged with Visual studio and found that getElementByTagName() function returns a null pointer while using the msxml6.dll library which in-turn further reference cause abort and it's working fine with msxml3.dll.
Is anyone know why this "unhandled exception" was there due to msxml6.dll? And How can i fix it?
Can you double check if the element has namespace? Probably this is because of the behavioral changes between MSXML3 and MSXML6 where MSXML6 is more compliant in terms of namespace. To fix this issue, you may want to use XPath instead.
Related
I am stuck at a strange issue in EntityFrameworkCore 3.1.2:
That is my application logging an error Further to my checks with .NET Reflector, I see that the assembly Microsoft.Extensions.DependencyInjection, Version 3.1.2.0 indeed references 3.1.0.0 of Microsoft.Extensions.DependencyInjection.Abstractions:
My application is targetted to net48.
I tried to narrow down the issue by writing a simple application, and it still gives the same error. Any help is much appreciated!
Edit: I figured out that the issue was caused by the fact that I have code in place to create an AppDomain and the faulting code was being executed inside that. I still don't know what is causing it. My assumption is the references should still work correctly inside a cusotm AppDomain.
My WPF application suddenly fails with the following exception:
System.IO.FileFormatException: No FontFamily element found in
FontFamilyCollection that matches current OS or greater: Windows7SP1
I've tried different OS but it's happening only on Windows 7 with SP1.
Microsoft released an official statement about this issue here (includes workarounds):
https://github.com/dotnet/announcements/issues/53
I've found out that the exception is connected to the latest security update KB4055532. When this update is uninstalled on Windows 7 SP1 then the problem disappear.
Since I'm not allowed to comment:
Answer by 'user2250152' is correct.
#Comment by #Lieven Keersmaekers:
'fwiw - installing KB4056894 also triggers this exception when starting Powershell ISE':
I really doubt this.
I'm dealing with this 'KB4055532' issue for 2 days now on all in all 8 machines. But after having installed 'KB4056894' there were no issues with starting Powershell ISE.
This only started to happen after installing 'KB4055532'.
And uninstalling this 'KB4055532' (but still having 'KB4056894' on the machines) resolves the issue with Powershell.
Btw:
There is a hint on the following site (and a way to 'fix' the issue):
https://ngb.to/threads/32709-Microsoft-Patchday-Januar-2018-KB4055532-NET-Font-Probleme.
The issue comes from a '*.CompositeFont' file that gets replaced by the update and which is then missing information for Windows 7. This makes programs based on WPF using functions to determine FontFamily fail/crash.
Effectively I'm quite sure it is only the file 'GlobalUserInterface.CompositeFont' that must be exchanged to temporarily fix this issue.
I ran into this error with MarkdownPad2. With the information from .NET Framework January 2018 Rollup Known Issue KB4074906 - "TypeInitializationException" or "FileFormatException" error in WPF applications (thanks #Boris!), I used the manual repair option to download and replace the corrupted font (installed by Microsoft's update) and it solved the problem.
The exception looks like this:
The invocation of the constructor on type 'MarkdownPad2.UserControls.MarkdownEditor' that matches the specified binding constraints threw an exception.
---> System.TypeInitializationException: The type initializer for 'System.Windows.Media.Fonts' threw an exception.
---> System.IO.FileFormatException: No FontFamily element found in FontFamilyCollection that matches current OS or greater: Windows7SP1
Damaging a font during an upgrade seems like an inexcusable error. Apparently Microsoft agrees, as they closed the tech note with this comment:
All updates are extensively tested before they are provided to you. We are investigating the gap in our testing and will resolve that for our next release.
I am currently faced with a dilemma in regards to adding any kind of DLL to a ColdFusion project. I have done a ton of research but nothing seems to be simplistic enough to grasp an understanding. I have a Winform that uses the same DLL in the Reference which makes life easy. When looking to add the same DLLs to a ColdFusion project, it doesn't seem to be working. I have tried using the following:
<cfobject type="com" name="myObj" assembly="C:\DocViewer\AxInterop.SHDocVw.dll">
Here is the error message I am receiving as well:
Attribute validation error for tag CFOBJECT. It has an invalid
attribute combination: assembly,name,type.
This site has been very helpful in the past and I am hoping to learn how this DLL in CF9 works so that I do not have to completely rewrite an entire program when the current one works perfectly.
From comments
I tried adding the DLL using the regsvr32 but here is my error now:
the module was loaded but the entry-point dllregisterserver was not found
Well it looks to me like you're using the cfobject attributes for a .NET object instead of for a COM object. The cfobject tag is one of those tags where the attributes vary by action/type, like cfcontent, cffile and cfdirectory (and a bunch of others that don't immediately spring to mind).
So you need the documentation for accessing COM objects specifically, which for the latest version of Adobe's CFML engine is located here: https://wikidocs.adobe.com/wiki/display/coldfusionen/cfobject%3A+COM+object
There's a typo on the docs page, but it looks like this should work for you (although I'll admit it's been a while since I've invoked a COM object):
<cfobject
type = "com"
class = "path.to.com.Class"
name = "myObj"
action = "create|connect">
It looks like you would use action="connect" if you have it installed as a Windows Service, or create if you want CF to instantiate the DLL, but I would guess having it installed as a service would be easier. I'm just guessing, but I think "path.to.com.Class" would be the name of the service if you're using it that way, or it would be the logical path to the .dll file if the CF server is instantiating it. If neither of those options work, then there might either be a version incompatibility if this is being moved to a newer OS, or the service might be misconfigured.
The error message from registering the DLL sounds like (and I'm guessing because I've never created a windows service DLL) it's looking for a specific class or function in the DLL in order to register it as a service in Windows and it can't find that "entry point" in the DLL (i.e. in the same way that Java will look for a "public static void Main(String args)" as the entry-point to a Java program). That may be necessary for a Service, but it's probably not necessary for a generic DLL that might be accessed and used in some other way, so it's possible this DLL might work, but not be compatible with Service registration.
So going back to your sample code, this might work:
<cfobject type="com" name="myObj" action="create"
class="C:\DocViewer\AxInterop.SHDocVw.dll">
When I launch my WPF application and when it goes to InitializeComponent function call of one user control, it silently quits and only leaves one message in the output window saying Managed (v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's how I normally find where the problem is)
Here is what I did: in this application project we need to use a reference Microsoft.Office.Interop.Owc.dll, with version number 10.0.4504.0. Since it is an interop library, when I added this reference in VS2012, it automatically sets the property Embedded Interop Types as true, which I assume means it will not keep an individual dll in the output folder but instead embed this library into the main output (at least this is how it seems in our other references, for example, Microsoft.Office.Interop.Outlook.dll). However, when I launch the project, it throws an XamlParseException saying:
"Could not load file or assembly 'Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system
cannot find the file specified.":"Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35""
It seems that the reference was not embedded(or the version is not currect. But I verified that the reference version is indeed 10.0.4504.0)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this library. This time the exception is not thrown, but the whole application just silently quits as I described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no article about it. I tried to set the Embedded Interop Types to true/false but the problem is the same.
UPDATE:
I'd like to add more description here. As mentioned above, the problematic library is OWC(Office Web Component)10. I followed this link to make OWC work with VB.NET desktop application: HOW TO: Handle Events for the Office Web Components in Visual Studio .NET. But this official article is so old so I had to make a lot of changes to compile the wrapper dll(mainly because of namespace mismatch). Then when I add the reference to the actual interop library Microsoft.Office.Interop.Owc, if I follow the default setting and let the Embedded Interop Types as True, at runtime it will complain (throw a XamlParseException) that the assembly cannot be loaded (see description above). What the hell? I thought make it as "embedded" would guarantee this library will be found. Then I copy this dll to the output folder, then I have this silently quit problem. But it might be worth mentioning that this time the output window shows the Microsoft.Office.Interop.Owc.dll is indeed loaded. Actually it is the last message before the managed has exited message. So it must still relate to this library.
All of this only happens with OWC10. There is actually a similar way to do that in OWC11(the latest, but unfortunately still pretty old version since it came with Office2003): HOW TO: Handle Events for the Office 2003 Web Components in Visual Studio .NET. But it actually works and the control is displayed on my application. It is because of some other reason that I wanted to try OWC10 instead of OWC11
When I launch my WPF application and when it goes to InitializeComponent function call of one user >control, it silently quits and only leaves one message in the output window saying Managed
(v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is >no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's >how I normally find where the problem is)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this >library. This time the exception is not thrown, but the whole application just silently quits as I >described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no >article about it. I tried to set the Embedded Interop Types to true/false but the problem is the >same.
I had exactly the same thing happening to me today, "has exited with code -1073740771 (0xc000041d)." (This happened in both a VB and C# .NET WinForms application for me). I tried debugging and saw I never even got into the Form_Load code block.
I "solved" this in the end by running visual studio as an administrator (and then just opening & building and running the project via the menu).
This is a win8 security issue and it isn't well explained anywhere.
(I got distracted and just opened up a specific project straight out of my task bar/solution file which caused this to happen to me).
You've probably found this out by yourself by now, hope you didn't lose any hair over it :)
Just pointing this out for other people who might have this error occuring somewhere.
Also had this issue, the 'silent' exit with code -1073740771 (0xc000041d) on x64 platforms, on x86 platforms everything was OK.
Part of my application is unmanaged C++, another part is C#. It turned out that my C++ code was not completely ready for the x64 platform. The following change fixed the issue in my case:
// before
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG>(WindowProc)));
// fixed version
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG_PTR>(WindowProc)));
So, the generic recommendation is to verify that your code is completely ready for the x64 platform.
I am using Microsoft.Build.BuildEngine.Engine to build a WPF application. This has been working successfully for class libraries and web applications, but now trying to use it to build a WPF application I am getting the following error:
Target MarkupCompilePass1:
c:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets(294,9):
error MC1000: Unknown build error,
'API restriction: The assembly
'file:///C:\Program Files
(x86)\Reference
Assemblies\Microsoft\Framework\v3.0\PresentationCore.dll'
has already loaded from a different
location. It cannot be loaded from a
new location within the same
appdomain.' Done building target
"MarkupCompilePass1" in project
"TestWindowsApplication.csproj" --
FAILED.
This application builds fine when building using VisualStudio 2008 (i.e. build from the menu), but using the Microsoft.Build.BuildEngine.Engine it throws this build error. Anyone know what is going on here?
I had the same problem and found this on msdn which says
By default, markup compilation runs in
the same AppDomain as the MSBuild
engine. This provides us significant
performance gains. This behavior can
be toggled with the
AlwaysCompileMarkupFilesInSeparateDomain
property. The latter one has the
advantage of unloading all reference
assemblies by unloading the separate
AppDomain.
So since the exception thrown stated that PresentationCore was loaded in the same AppDomain I switched this property using:
projectToBuild.SetProperty("AlwaysCompileMarkupFilesInSeparateDomain", "True");
Which seemed to be the key.
I hope this helps.
Now that is interesting! Check out this issue I hit last week. Same exception and error message, and related to WPF.
If you have a look at the comments for the MSBuild MarkupCompilePass1 task throwing the exception, it may be a clue as to why it's working inside VS2008 but not from your MSBuild process:
<!--
When performing an intellisense compile, we don't want to abort the compile if
MarkupCompilePass1 fails. This would prevent the list of files from being handed
off to the compiler, thereby breaking all intellisense. For intellisense compiles
we set ContinueOnError to true. The property defined here is used as the value
for ContinueOnError on the MarkupCompilePass1 task.
-->