Local Security Authority LabView 2024 Q3

[GabeJ]

I was trying not to get too into the weeds here, but since there is some interest, I'll explain a couple of things:

1. Microsoft has a concept called "Protected Process Light" that came around in the Windows 8.x timeframe.  Processes can be protected with various levels of security.  Only modules that are signed with certificates that convey that level of security can be loaded into such a process.  Crowdstrike has a thorough explanation of this if you are interested in more details.
   
   You can use SysInternals' Process Explorer to show the protected processes running in your system.  (You have to add the Protection column to the display and then use File->Show Details for All Processes.)  Here is an example from my system (with the virus scanner process name elided):
   
   
   For ages now, if a DLL that wasn't signed for one of these levels was loaded into a process, you'd get a message in Event Viewer to that effect, as you've noted.  When Event Viewer says that LxiMdnsNdp.dll doesn't meet the "Microsoft level" signing requirements required by svchost.exe, it means that DLL doesn't have the appropriate Microsoft signature to be securely loaded in that instance of the svchost.exe process.  MpDefenderCoreService is a virus scanner, so it expects to only load DLLs that are signed for Anti-malware (ELAM), thus the "did not meet Custom 3 / Antimalware" message in your other example.
   
   Further complicating things, last year Microsoft enabled by default a pop-up when an attempt is made to load an improperly signed DLL into the lsass.exe process.  It was at that point that concern about this longstanding problem began to blow up.
   
   Microsoft doesn't dole out most of these signatures to just anyone.  Developers *can* get the LSA signature, and the NI DLL does have that in its latest iteration.  The LSA signature gets rid of the pop-up and the lsass.exe warnings in the Event Viewer, but warnings from all other processes will still be present.  ELAM signatures are allocated much more strictly.  I don't think third-party developers can get the other signatures at all.
2. It's not just a problem with Bonjour/mDNS DLLs.  It is any DLL that is not signed properly for loading in one of these processes.  The mDNS DLLs tend to show it frequently because they are Winsock Namespace Service Providers.  Essentially, they plug into the Windows networking stack and augment its name resolution services.  As such, any process that uses Windows networking for name resolution will end up trying to load these plugins.  If it is a protected process, the message is displayed in Event Viewer.

[softball]

Hi

Thanks for the detailed response.

However, I notice that you mention 'warnings' about the missing functionality.

I see fatal 'errors' as shown in the screendumps.

I did notice and did read CrowdStrike's long explanation. Obviously it is not meant for mortals.

I understand now that Microsoft may have restricted the functionality of software trying to use the Bonjour protocol. Because it is so powerful. Reminds me of the long standing allowing reading CHM or not allowing CHM. The jury is still out on that.

It puzzles me that Bonjour support is not just a 'it works' or 'it does not work' question.

- NI's Bonjour version ( as well as Keysight's ) got blocked on this computer.

- But Apple's original stone-age Bonjour version from 2015 works just fine. Did Microsoft silently allow it ?

For anyone wanting to try out whether they have Apple Bonjour support or not, and which devices then responds to Bonjour, one can download this little tool : 

https://hobbyistsoftware.com/bonjourbrowser

Apple's Bonjour is not available as a self contained download. It is/was only available as part of an iTunes for Windows installation.

Regards

PS : I just read that 24H2 started giving warnings where 23H2 did not. So subject diagnostics in flux ..  

[GabeJ]

> However, I notice that you mention 'warnings' about the missing functionality. I see fatal 'errors' as shown in the screendumps.

Yes, I was being a bit glib.  I call them warnings because they show up in the logs but don't in general seem to have other impacts.

> I understand now that Microsoft may have restricted the functionality of software trying to use the Bonjour protocol.

Maybe, but again the errors we are talking about here aren't exclusive to Bonjour.  They apply to any DLL that is loaded in an unsupported protected context.

Microsoft has also recently added multicast DNS support directly into Windows 10, so they may want to encourage developers to use the native implementation.  

> But Apple's original stone-age Bonjour version from 2015 works just fine. Did Microsoft silently allow it ?

I wouldn't put it past them.  iTunes was so widely available that MS may have given it special dispensation.

[softball]

Hi

I am out of my comfort zone of knowledge. So, as my final action I draw on Google rumor based AI :

Windows 10 has some built-in Multicast DNS (mDNS) support for specific features like discovering printers and wireless displays, but this is limited to modern APIs, not all applications, and can be unreliable due to potential firewall or configuration issues.

For full, cross-application mDNS support in Windows 10, users typically need to install a third-party service like Apple's Bonjour Print Services.

Built-in vs. Third-Party mDNS

• Limited Built-in Support: Microsoft implemented mDNS support starting with Windows 10 version 1703 but primarily for modern Universal Windows Platform (UWP) applications, not traditional Win32 applications. 

• Third-Party Requirement: To enable full mDNS support across all applications, you must install a third-party solution, such as Apple's Bonjour services. 

Why the Difference Matters

• Application Compatibility: Windows 10's native mDNS is only available to apps designed to use the newer Windows APIs, which is a small subset of most applications, according to Super User and Stack Overflow. 

• Bonjour Services: Installing Apple's Bonjour enables the full, robust mDNS functionality and provides the necessary drivers and services to allow applications to discover services on the local network using mDNS. 

If You Need to Use mDNS on Windows 10

1. Install Bonjour: Download and install Bonjour Print Services for Windows.
2. Check Services: Ensure the Bonjour service is running.
3. Adjust Firewalls: Verify that your firewall settings are not blocking mDNS traffic, as this is a common cause of mDNS issues on Windows.

So, Microsoft started a half-hearted initiative around 2017 but seems to have lost interest in the subject.

And ( apparently  ? ) never updated it.

Regards