Xibo v3 support for Windows 11

Get Help Xibo Player for Windows
1

Before completing please check that the time, date and timezone have been correctly set on the device running the Player.

To be completed by the original poster:

Player Version

Specify the full version you are using, including the revision number.
3.309.1

Issue

Please describe in detail the issue you are experiencing, including any errors shown on the Player Status page or in the Logs section of the CMS.
Even though the Xibo v3 player does not claim to support Windows 11 (even though I believe it should due to the fact all new machines come with it and the EOL of Windows 10 is quickly looming) I had it working fine on Windows 11 21H2 for the longest time. However, when I upgraded the OS to Windows 11 22H2 the Xibo client fails to launch with an error of
Fatal Error initializing the application. Exception from HRESULT:0xD0000003
The watchdog launches fine.
After researching what could’ve changed, with the error code being pretty generic, a few articles about other products pointed to a version of the Visual C++ libraries, where installing an older version of the libraries, if you can find it, may help. Comparing the versions of an old Windows 10 and this problematic one, they do differ. Perhaps if this player was recompiled with the newer libraries under windows 11 is all it needs, or if I could get my hands on the exact version of the libraries that originally came with the player I could fix this. Completely uninstalling the client, and then all of the C++ redistributables before reinstalling did not work. The versions of that did not match the old Windows 10 list of distros.

Provide screenshots where possible!

image
image1128Ă—614 85 KB

2

Hi and welcome!

Our development of the player happens using W11, so we expect it to be fully supported (the only minor exception we have currently reported is that we can’t open the on screen keyboard for some reason).

This error comes from here: xibo-dotnetclient/MainWindow.xaml.cs at develop · xibosignage/xibo-dotnetclient · GitHub, and I’m not sure we’ve ever had an error raised at that point before. The contents of that block start up all of the communication threads, and so the error could be anywhere!

The error handling there is poor and doesn’t really give us much information to work with. I’ve reported the poor error handling and will try to get a beta player to you sometime next week which points us in the right direction.

We include these as a dependency with the installer, but later versions should work also. I don’t think the error touches the part of the application that needs these, but it was a good idea.

1 Like
3

Regarding that Redistributed library, even though you include the installer, it looks like a bootstrapper and downloads the latest one from Microsoft during that pre-installation. The resultant version of the x86 visual c++ libs are:

image
image876Ă—48 2.43 KB

Which I think is the latest… I thought that too that uninstalling xibo and all distros and trying again would restore those versions to what you included. This looks like that’s not the case and the version of the c++ libs are a moving target. The installation of these right from your installer shows that.
image
This happened simultaneously on only the 2 Windows 11 computers we have running Xibo, while my old Windows 10 ones kept going. To rule out any hardware issues because these 2 computers are identical and unique (Mele mini computers) I did it on my regular dell latitude with the exact same OS and patch level. Same error. And yes, the xibo installer ended up upgrading my version of the distro (x86) to that new version number. So my theory of the version of the visual c++ libs matching what the xibo installer originally intended to install is indeed ignoring what’s included and goes ahead and gets the latest from MS somehow.

4

Ok, so I went to a Windows 10 computer that’s successfully running the same client and compared the Visual C++ redistributed libraries and then grabbed the absolute latest version from MS and upgraded it to see if it too would start failing in the same way. It’s actually newer than what has been appearing (14.36.), it ran just fine. Latest patch level of Windows 10 22H2.
So, not to compare apples and oranges, I applied the same 14.36. libraries to my Windows 11 22H2 computers to no avail. Still throwing that same error.

5

We specify a minimum version check of 14.30 and if that isn’t installed we download the following file and prompt the user to install it:

https://download.visualstudio.microsoft.com/download/pr/2250605e-e48f-43ed-ba6e-e0cc18bc530d/AC75A82D873E6B6F98B1D293042380764D7D263C43438E50D564FA58C9F891C2

It may turn out to be something to do with the C++ libraries, but until we have a better error message reported, I don’t think we can rule out another root cause.

I have created an exe which you can download here (link expires in 3 days) and replace your existing installations XiboClient.exe file. You may need to right click and “Unblock” the exe before it will run. The error message you get should have a stack trace included which will help us pin point the error.

6

Ok, so I did this and got the warning and unblocked it (or “Run anyways”).

Unfortunately at that point nothing seems to be happening. The task manager

shows it’s running, and it launches the watchdog like it usually does.

I’ve left it running in case it was spending time collecting the logs but

still nothing. Nothing in the Event logs either.

7

You may need to actually “Unblock” the file by right clicking on it in windows explorer and selecting unblock.

Have you configured the player using Player Options? If so, can you see if any log.xml files are being created in your local library folder?

8

There is no “unblock” when I look at that executable, so I’m assuming that

it hasn’t been tagged as blocked.

I didn’t have that account I was working from configured, but the generic Xibo splash

slide would still come up. However, I switched to the account that actually runs the

signage and same results. No response, and I can’t even bring up the Xibo configure

application.

I grabbed the last attempt at running its log… there’s that same HRESULT error…

<trace date="2023-07-24 07:51:19" category="Error"><logdate>2023-07-24 07:51:19</logdate><thread></thread><method>Main</method><message>Unhandled Exception: Startup: Exception from HRESULT: 0xD0000003</message>

</trace>

<trace date="2023-07-24 07:51:19" category="Error"><logdate>2023-07-24 07:51:19</logdate><thread></thread><method>Main</method><message>
Stack Trace: at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.CodeDom.Compiler.FileIntegrity.MarkAsTrusted(SafeFileHandle safeFileHandle)
at Microsoft.CSharp.CSharpCodeGenerator.FromSourceBatch(CompilerParameters options, String[] sources)
at Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromSourceBatch(CompilerParameters options, String[] sources)
at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource(CompilerParameters options, String[] sources)
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.GetSerializersFromCache(XmlMapping[] mappings, Type type)
at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Type type)
at System.Web.Services.Protocols.SoapClientType..ctor(Type type)
at System.Web.Services.Protocols.SoapHttpClientProtocol..ctor()
at XiboClient.xmds.xmds..ctor()
at XiboClient.OptionsForm..ctor()
at XiboClient.App.OnStartup(StartupEventArgs e)</message>
</trace>
9

We have seen something similar recently before and it turn out to be something called “Windows Lockdown Policy”.

It wasn’t exactly the same, but very similar.

The prior issues also came from System.Web and showed as a violation in Windows Event Viewer under Windows Logs → Application and Service Logs → Microsoft → Windows → CodeIntegrity → Operational

Disabling the policy was the only way around the previous issue.

I did wonder whether we should be code signing all the DLL’s in our installation package, but I am not sure about that.

10

I think you’re onto something here. I opened up that log location and launched the Xibo client.

Although these were just informational items, not errors.

Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\SysWOW64\cmd.exe) attempted to load \Device\HarddiskVolume3\Program Files (x86)\Xibo Open Source Digital Signage\watchdog\x86\XiboClientWatchdog.exe that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{a244370e-44c9-4c06-b551-f6016e563076}). However, due to code integrity auditing policy, the image was allowed to load.

Signature information for another event. Match using the Correlation Id.

Signature information for another event. Match using the Correlation Id.

I didn’t think defender could be the culprit because the Windows 10 22H2 clients also have

the same defender running on it and they’re working just fine. If that’s it then it would

have to be a feature in Windows 11 that defender may leverage that it doesn’t in Windows 10.

11

Hmm, that’s interesting!

I did a little research into whether or not we should sign the DLLs in the install folder too, and the general consensus seems to be no. At this point I don’t really know where to look next!

12

Thanks for trying, I’ll keep trying here and will post the solution

if I come up with something.

Guy

1 Like
13

An update, we also recently switched to a corporate version of Microsoft defender on top of the Windows 11 feature update and in an experiment, I re-installed our old antivirus product (because you can’t just turn off defender without another product in place) and it began working again. So, because it was working on a plain Windows 11 computer with the default defender on it, I’m blaming the tight corporate settings on Defender that broke this. With that being said, we have encountered no other product on any of our computers that has failed in this manner, so the binaries for the Xibo v3 client do fail some scrutiny and could be fixed. I’m going to take my other case and slowly loosen up on the Defender settings to see if I can determine where this product is failing.

14

Thanks for the update; we’re happy to make any adjustments we can that are under our control. If would be great if you’re able to isolate the root cause.

15

A new update, my last fix for this was to offboard the running Defender which applied a bunch of unknown, assuming very restrictive, policies over and above the default ones which we have set locally. That worked great, not ideal, for months. However, the recent Cumulative Update For Oct 2023 from Microsoft for Windows 11 has brought back this error. Still, Windows 10 with the latest patch continues to work. Still no issues with any other applications that we run here that have a similar behaviour on Windows 11 machines, just the Xibo client.
I’m wondering if this is a losing battle as MS tightens security with Windows 11 going forward with every patch. So I’m wondering what’s different with this Xibo client?

16

On start up Xibo does start the watchdog tray application, so you could try renaming XiboClientWatchdog.exe so that it does not do that.

Interestingly we do sign that EXE, but perhaps there is a windows defender restriction still preventing it.

image
image794Ă—179 4.07 KB

17

So I renamed both the x86 and x64 versions of the watchdog to no avail. Same error message as before. The watchdog no longer launches as expected. I’ll go through those logs again to see what’s there.

18

Thanks for trying - at least we’ve been able to rule that out.

19

Ok, this one is new… along the same lines as the watchdog error though.
Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files (x86)\Xibo Open Source Digital Signage\CefSharp.BrowserSubprocess.exe) attempted to load \Device\HarddiskVolume3\Program Files (x86)\Xibo Open Source Digital Signage\vk_swiftshader.dll that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{a244370e-44c9-4c06-b551-f6016e563076}). However, due to code integrity auditing policy, the image was allowed to load.

I looked at the file and there’s no digital signature on vk_swiftshader.dll compared to something like System.Memory.dll which does have one.

20

Continued down the list:
CefSharp.BrowserSubprocess.Core.dll
CefSharp.BrowserSubprocess.exe
XiboClient.exe
I tried restarting the client to regenerate these errors, and low and behold this time errors were logged instead of informational logs. This time surrounding a slew of files from the .NET framework.
Here’s one example:
Code Integrity determined that \Device\HarddiskVolume3\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe is trying to load \Device\HarddiskVolume3\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll which failed the dynamic code trust verification with error code of 0xC0000225.
I checked against Microsoft for any linger patches, and it did not come back with any.