xBimTeam / XbimGeometry

XbimGeometry contains the CLR interop libraries and the c++ engine used to compute the 3D geometry of models.
https://xbimteam.github.io/
Other
260 stars 132 forks source link

Is XbimGeometry supposed to work on Windows 7 machines? #154

Open TruePsyker opened 5 years ago

TruePsyker commented 5 years ago

The reason I ask is that loading Xbim.Geometry.Engine64.dll (via XbimCustomAssemblyResolver) crashes application with ExecutionEngineException on my Win 7 machine. In contrast it works fine on Win10. Are there any tricky prerequisites should be met to get the library work on Windows 7?

andyward commented 5 years ago

Can't think of any reason why it would not work under Windows 7. It's more likely down to how the unmanaged GeometryEngine DLL is resolved.

Some questions:

Are you running in a 64 bit process? What kind of application is it (Console, Web app, windows?) What version of XBIM Geometry? What error are you seeing?

TruePsyker commented 5 years ago

The application is a 64bit net47 Windows app using xBim essentials version nuget v5.0.213 and geometry version nuget v5.0.163. Logs says it can't find Xbim.Geometry.Engine64.dll or its dependencies. But it does exist in Bin folder next to all other DLLs and the executable itself. I think either there is a dependency issue (geometry lib for example uses net-standard2.0 logging lib) or problem with unmanaged code.

andyward commented 5 years ago

Can you provide the logs? There's various points the probing can go wrong. I doubt it's anything to do with the logging lib. Most likely option is you've not got the correct VC runtime on windows 7.

andyward commented 5 years ago

Pretty certain this will be a VC Runtime issue.

From @SteveLockley đź‘Ť

We are using Windows runtime 10.0.15063.0 And VC Platform toolset 141 [The VC runtime should be this one] https://go.microsoft.com/fwlink/?LinkId=746572

guenter1holzeder commented 5 years ago

We have the same issue on our test machines: Windows 10 => OK Windows 8.1 x86 => OK Windows 8.1 x64 => OK Windows 7 x86 => Crash Windows 7 x64 => Crash

We used XBimExplorer and a simple console application for testing. We installed all necessary VC runtimes.

Event log from Windows 7 x64 see attached file: XbimExplorer Windows 7 x64 event log.txt

martin1cerny commented 5 years ago

Windows 7 will be missing Visual C++ Redistributable for VS 2017. You need to distribute this alongside the binaries.

guenter1holzeder commented 5 years ago

We did this with several VC versions and also with different frameworks 4.7.x - always with the same result…

image

OrcaIfc commented 5 years ago

Did you ever test it on Win7 on your own? We can't get it run as guenter has written above, but it would be very important for us.

andyward commented 5 years ago

Have you tried install the Windows Software Development kit 10.0.15063 from https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

According to https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk ... you may need to install a KB2999226 on Windows7 before you install.

My understanding is that the Windows SDK is a superset of the old VC runtime. We build against version 10.0.15063

OrcaIfc commented 5 years ago

Hello Andy,

I’ll investigate that today an send you my response. Thank you very much for your help.

Best regards,

OrcaIfc commented 5 years ago

Hello Andy,

we installed exactly the same kit and tried it with newer ones, too.

We also installed the KB2999226.

But still it crashes. It’s already when we load the assembly. With the x86-Version we got an FatalExecutionEngingError with Errorcode: 0x80131506, which could be a problem in the CLR or Marshall Errors for COM-Interop or PInvoke.

But there was an other error fort he x64-Version.

By the way, we use the x86-Version.

Best regards,

SteveLockley commented 5 years ago

There is no reason why the source of the geometry engine should not run on windows 7.

I would suggest downloading the source and building your own DLL on your machines, my guess is it will almost certainly be the c runtime libraries

Steve Lockley Mob: 079 67 600 923


From: OrcaIfc notifications@github.com Sent: Tuesday, March 5, 2019 10:23:10 AM To: xBimTeam/XbimGeometry Cc: Steve Lockley; Mention Subject: Re: [xBimTeam/XbimGeometry] Is XbimGeometry supposed to work on Windows 7 machines? (#154)

Did you ever test it on Win7 on your own? We can't get it run as guenter has written above, but it would be very important for us.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/xBimTeam/XbimGeometry/issues/154#issuecomment-469625815, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH13pfxxo7Qo_3W3IWedpvQlo8eebrZhks5vTkWOgaJpZM4Z-lTA.

This message is intended solely for the addressee and may contain confidential and/or legally privileged information. Any use, disclosure or reproduction without the sender’s explicit consent is unauthorised and may be unlawful. If you have received this message in error, please notify Northumbria University immediately and permanently delete it. Any views or opinions expressed in this message are solely those of the author and do not necessarily represent those of the University. Northumbria University email is provided by Microsoft Office365 and is hosted within the EEA, although some information may be replicated globally for backup purposes. The University cannot guarantee that this message or any attachment is virus free or has not been intercepted and/or amended.

OrcaIfc commented 5 years ago

We compiled it again on Win 7, with KB2999226 and the SDK installed. It is still the same. I get error for both, the Xbim.Geometry.Engine32.dll and the -64.dll.

I tried it with Xbim Explorer as well as a console application, the just tries to load the assembly.

andyward commented 5 years ago

Can you enable the logging? If you've got the latest v5 xbim Xplorer there's an option to turn on verbose logging, and a developer option to show the logs.

(There's quite a bit of logging in the geometry engine resolver around this area)

OrcaIfc commented 5 years ago

Can you enable the logging? If you've got the latest v5 xbim Xplorer there's an option to turn on verbose logging, and a developer option to show the logs.

(There's quite a bit of logging in the geometry engine resolver around this area)

Here it is.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/xBimTeam/XbimGeometry/issues/154#issuecomment-470153549, or mute the threadhttps://github.com/notifications/unsubscribe-auth/As_PAsExptxDK6lp57cJjezLrnG_0YIAks5vT-ApgaJpZM4Z-lTA.

2019-03-06 17:02:33.899 +01:00 [INF] Xplorer started... (1) 2019-03-06 17:03:22.876 +01:00 [INF] GeomScene: Xbim3DModelContext [Unable to find any Geometric Representation contexts with Context Type = model and Context Identifier = , using Context Type = 'Design' instead. NB This does not comply with IFC 2x3 or greater, the schema is IFC2X3] (3) 2019-03-06 17:03:22.909 +01:00 [INF] Starting creation of model scene (3) 2019-03-06 17:03:22.912 +01:00 [DBG] Loading Xbim.Geometry.Engine.dll (3) 2019-03-06 17:03:22.916 +01:00 [DBG] Getting probing path from executing assembly (3) 2019-03-06 17:03:22.916 +01:00 [DBG] Probing path C:\Users\Ultimate\Desktop\XbimWindowsUI-master\Output\Debug\net47 (3) 2019-03-06 17:03:22.916 +01:00 [DBG] Probing for GeometryEngine in C:\Users\Ultimate\Desktop\XbimWindowsUI-master\Output\Debug\net47\Xbim.Geometry.Engine64.dll (3) 2019-03-06 17:03:22.916 +01:00 [VRB] Loading C:\Users\Ultimate\Desktop\XbimWindowsUI-master\Output\Debug\net47\Xbim.Geometry.Engine64.dll (3) 2019-03-06 17:06:26.612 +01:00 [INF] Xplorer started... (1) 2019-03-06 17:06:38.604 +01:00 [INF] GeomScene: Xbim3DModelContext [Unable to find any Geometric Representation contexts with Context Type = model and Context Identifier = , using Context Type = 'Design' instead. NB This does not comply with IFC 2x3 or greater, the schema is IFC2X3] (7) 2019-03-06 17:06:38.624 +01:00 [INF] Starting creation of model scene (7) 2019-03-06 17:06:38.625 +01:00 [DBG] Loading Xbim.Geometry.Engine.dll (7) 2019-03-06 17:06:38.628 +01:00 [DBG] Getting probing path from executing assembly (7) 2019-03-06 17:06:38.628 +01:00 [DBG] Probing path C:\Users\Ultimate\Desktop\XbimWindowsUI-master\Output\Debug\net47 (7) 2019-03-06 17:06:38.628 +01:00 [DBG] Probing for GeometryEngine in C:\Users\Ultimate\Desktop\XbimWindowsUI-master\Output\Debug\net47\Xbim.Geometry.Engine64.dll (7) 2019-03-06 17:06:38.629 +01:00 [VRB] Loading C:\Users\Ultimate\Desktop\XbimWindowsUI-master\Output\Debug\net47\Xbim.Geometry.Engine64.dll (7)

andyward commented 5 years ago

Looks like VC runtime issues. I'll see if I can spin a Win 7 VM up tonight and take a look...

LucianoOhneO commented 5 years ago

@andyward

Hello Mr. Ward

I have some updates on this issue...

I have tested the assembly load process of the Geometry.Engine on Windows 7 (The same procedure like your unit test “LoadGeometryEngine”).

When I try to load the 64Bit Version of the dll with a 64Bit application, the load process it will hang-up without error/exception.

For the other cases (64 bit application with 32bit dll and 32 bit application with 32bit dll) the Debug throws the following Exception:

„LoaderLock was detected Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.“

Furthermore after i disable the „LoaderLock“ check, the Debugger will throw the following exception:

„Managed Debugging Assistant 'FatalExecutionEngineError' Message=Managed Debugging Assistant 'FatalExecutionEngineError': 'The runtime has encountered a fatal error. The address of the error was at 0x73ba5cb3, on thread 0x1250. The error code is 0x80131506. 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.'"

and the Debugger Console shows the following exception:

'AssemblyCheck.exe' (CLR v4.0.30319: AssemblyCheck.exe): Loaded 'C:\Users\Ultimate\Desktop\AssemblyCheck\AssemblyCheck\bin\x86\Debug\Microsoft.Extensions.Logging.Abstractions.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. Exception thrown: 'System.BadImageFormatException' in mscorlib.dll Managed Debugging Assistant 'FatalExecutionEngineError'

I have no experience with C++ and native DLL`s. Can you see a problem regardless the unmanaged DLL initialisation under specific circumstances (for example Windows7 and .Net 7.2 ) ? Do you use another initialisation method?

[Update] Maybe it is related to this action: https://github.com/xBimTeam/XbimGeometry/issues/93#issuecomment-437331144

I have found the following post: https://stackoverflow.com/questions/56642/loader-lock-error There is an entry with the following information:

UPDATE FOR .NET 4.0 AND MORE RECENT FRAMEWORKS This is an old question asked at the time of .Net 2.0, when support for mixed mode DLLs had serious initialization problems, prone to random deadlocks. As of .Net 4.0, the initialization of mixed mode DLLs has changed. Now there are two separate stages of initialization:

  1. Native initialization, called at the DLL's entry point, which includes native C++ run-time setup and execution of your DllMain method.
  2. Managed initialization, executed automatically by system loader. …….

Some information over the initialization of mixed assemblies and „loaderLock“you can find here: https://docs.microsoft.com/en-us/cpp/dotnet/initialization-of-mixed-assemblies?view=vs-2017 https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/loaderlock-mda https://docs.microsoft.com/en-us/dotnet/api/system.badimageformatexception?redirectedfrom=MSDN&view=netframework-4.7.2

Maybe there are helpful …

Best Regards, LB.

andyward commented 5 years ago

Sorry, didn't get around to this last night. I need to get a Windows 7 image...

The 'BadImageFormatExceptions's are what I'd expect when loading 64 bit dlls into a 32 bit process (and vice versa). So I guess the question is why does 64bit in 64bit lock up and 32 in 32 not do the same.

When you say you set up a test, what are you running? A Console or Windows app? A Unit Test? Some kind of Web Test?

I suspect the loaderlock errors are a result of the debugger and/or the test application config. If you can share your test harness that would be useful

guenter1holzeder commented 5 years ago

A simple (.Net Framework) Console with a hard coded "Assembly.Load" and a full path to the Geometry-DLL will simulate the issue described above.

LucianoOhneO commented 5 years ago

@andyward

Hello Mr. Ward

I have done the testing on a Windows 7 /x64 (with Sp1) and Visual Studio 2017 (latest build).

An minimal test is to use the XbimWindowsUI project. Just start it and load a file. The result it will be: grafik Debug console output: grafik

For test purpose and a better issue localization i have write an .Net Framework console application which is doing the same load process from XbimCustomAssemblyResolver.cs/ LoadAssembly: grafik My test: grafik

andyward commented 5 years ago

Sorry I'm not sure what more I can do - I don't run Windows 7 and VirtualBox is blue-screening my machine when I try to install an Win 7SP1 ISO. I can't really spend any more time on this.

In terms of the exceptions you're seeing: the last one (BadImageFormatException) is saying you're loading the wrong type of DLL for the process - so I suspect you have something set up wrong in your AssemblyCheck test harness - i.e. you're masking the issue.

The real error you're seeing (AccessViolationException) is what you get when the C++ runtimes are not installed correctly. I guess this could be the case even with VS2017 installed if you've not installed the c++ packages. Make sure you have the VS 2017 VS Redistributable installed.

image

BjDi commented 5 years ago

Hi Andy, can you run HyperV on your machine?

We only got MV C++ 2017 Redistributables 14.16... Could you send us the download link for 14.20....

andyward commented 5 years ago

I do have HyperV - will take a look later.

I suspect it's because I've got VS 2019 Preview installed. 14.16 should be good enough - my slightly old copy of VS2017 comes with 14.14. They key thing is they support VC141 platform.

You might be able to find other versions in \Program Files (x86)\Microsoft Visual Studio\{Year}\{SKU}\VC\Redist\MSVC\14.xy.nnnn

BjDi commented 5 years ago

Could there be a problem with the "Target Platfrom", set to Windows 10 in the Geometry Project? See https://docs.microsoft.com/en-us/cpp/ide/general-property-page-project?f1url=https%3A%2F%2Fmsdn.microsoft.com%2Fquery%2Fdev15.query%3FappId%3DDev15IDEF1%26l%3DDE-DE%26k%3Dk(VC.Project.VCConfiguration.AppSupport);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.7);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.7);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.7)%26rd%3Dtrue&view=vs-2017

image

andyward commented 5 years ago

Good spot. I'll give that a go locally. @SteveLockley do you remember why you upgrade to Windows 10 SDK from 8.1?

andyward commented 5 years ago

So I've built a version of Geometry targeting 8.1 and built XbimXplorer against it (in the win7 branch) https://github.com/xBimTeam/XbimWindowsUI/commit/21518eb1aa8018b193758195002b7e41ad772b8a

Does anyone want to try it out in their Windows 7 envs? It seems fine in Win10.

If this is fine I'd propose we fold this back into develop/master

BjDi commented 5 years ago

It's still raining cats and dogs :-( It crashed. I locally compiled it without having SDK 8.1 installed without an error message. But my colleague couldn't compile it without having SDK 8.1 installed. Then we found the following link, making it clearer. https://developercommunity.visualstudio.com/content/problem/167806/windows-sdk-version-81-requires-100102400.html What I ask my self is, whether the pragmas are set correct for _WIN32, _WIN32_WINNT, ... are defined as proposed in https://docs.microsoft.com/en-us/cpp/ide/general-property-page-project?f1url=https%3A%2F%2Fmsdn.microsoft.com%2Fquery%2Fdev15.query%3FappId%3DDev15IDEF1%26l%3DDE-DE%26k%3Dk(VC.Project.VCConfiguration.AppSupport);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.7);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.7);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.7)%26rd%3Dtrue&view=vs-2017

And maybe there is another important note in it:

image

andyward commented 5 years ago

I started off by adding a targetver.h in with those #defines but thought I'd test without - I just changed the Platform Tool to 8.1.

I can try hooking that in and rebuilding.

andyward commented 5 years ago

@BjDi Thanks for the help & feedback so far. I've just pushed out another Geometry build with targetver.h setting WINVER etc to 8.1 which should also support Win 7. I've no idea if this works or not! When the build is done, do you want to see if you can try out with GeometryEngine5.0.174 in develop

BjDi commented 5 years ago

@andyward Thanks for your help, too. It didn't work. The defines in targetver.h has been set to Windows 8.1, we need to run it on Windows 7, and it didn't work. But when I changed them for Windows 7, same result as before. Seems it doesn't take any effect.

CBenghi commented 5 years ago

@andyward, I do have a windows 7 machine back at the office in NCL that I should be able to use for internal debugging. I'll assign this issue to myself, but @BjDi, please remind me in a while if there are no updated. Best, Claudio

BjDi commented 5 years ago

@CBenghi Thank you very much for looking at that problem with Windows 7.

Today I compliled the the maintenance/xBim4.x branche with Visual Studio 2013. (Plattformtoolset v120; .NetFrameword 4.5.2) That seems to be ok on Win7. Do you think it's possible (if there is no other solution), that we could compile all with v120, that means with all the important changes of the master branche?

Or is there a need, to do it with v141 (beside the logger)? Of course only as a fall back solution

guenter1holzeder commented 5 years ago

After time intensive collaboration with my colleagues @BjDi and @LucianoOhneO we found a way to get Xbim 5.0 run under Windows 7.

The simple way is to change the toolset for Xbim.Geometry.Engine back to V120 and everything will be fine. It seems there is no need to switch to V141 besides two unimportant attributes in XbimGeometryCreator.cpp. To get this way of building done see is-there-a-way-to-install-platform-toolset-v120-on-visual-studio-2017

We didn't find the real reason why Windows 7 crashes when loading the assembly. We guess it is a bug resulting from a combination of "Mixed Assemblies" with the new (URT) which is a breaking change since VS 2015.

Maybe there is another way of solution with the new toolset!?

daveime commented 5 years ago

The simple way is to change the toolset for Xbim.Geometry.Engine back to V120 and everything will be fine. It seems there is no need to switch to V141 besides two unimportant attributes in XbimGeometryCreator.cpp.

Tried this on a Windows 7 SP1 64 bit machine with Visual Studio 2017 and Visual Studio 2013 installed (for the v120 toolset) - therefore I have the C++ Redistributables for both 2017 and 2013 versions on my machine.

Commented out the two offending lines in XbimGeometryCreator.cpp, and also had to add #include \<algorithm> in xbimFace.cpp to avoid it complaining about std::max. I also found I had to remove any references to "DebugFull" and replace them with "false" in the "Xbim.Geometry.Engine.vcxproj" and "Xbim.Geometry.Engine - OCC.targets" files, as they seemed to croak on the v120 toolset.

Note, as soon as I selected the v120 toolset, the option to choose the SDK disappeared, so I have no idea which SDK version it's using (or indeed if it's using one at all).

Once built, I replaced the NuGet downloaded versions with my source built versions for the following.

Xbim.Geometry.Engine.Interop.dll (plus the .pdb and .xml files) Xbim.ModelGeometry.Scene.dll (plus the .pdb and .xml files) Xbim.Geometry.Engine32.dll Xbim.Geometry.Engine64.dll

Together with Xbim Essentials 5.1.259 in a NET 4.7 C# commandline project ...

Debug x86 / x64 - Geometry generation appears to work correctly, but application crashes on exit with Exception c0020001 in KERNELBASE.dll. However, I'm not sure if this is because I hacked the debug settings, or there is some issue releasing the C++ DLL properly.

Release x86 / x64 - Geometry generation appears to work correctly, no application crash on exit.

Gecc42 commented 5 years ago

Hello,

I have the load error on Xbim.Geometry.Engine64.dll but I can't understand why.

I'm on Windows 7 SP1 x64. I have a sample project (see attached Code.jpg) which run under VS2019 and .NET 4.7.2 (x64 configuration), and use Xbim.Essentials 5.1.271 and Xbim.Geometry 5.1.257.

I have all required VC++ installed (see attached VC.jpg), and the Xbim.Geometry.Engine64.dll is present in my bin/x64 directory.

The exact same project works on Windows 10, but I have the error on Windows 7.

Have you a solution for this issue ? I've read the thread but I can't figure out.

Thank you in advance :)

VC Code

guenter1holzeder commented 5 years ago

See my comment above

At this time we found no other solution for that issue

Gecc42 commented 5 years ago

Ok, thank you for your quick answer and information.