saroot 2 Posted November 14, 2018 Share Posted November 14, 2018 Hi All, I am getting windows server 2016 event log error as "SQL Server Native Client 11.0: Unable to load sqlnclir11.rll due to either missing file or version mismatch. The application cannot continue." after update from ESET File Security 6 to 7. Environment as : Windows Server 2016 EFS 7.0.12014.0 MSSQL Server 2014 Any one have a solutions for this? Thanks. gabrielk and Alberto T. Gomez 2 Link to comment Share on other sites More sharing options...
gabrielk 0 Posted November 25, 2018 Share Posted November 25, 2018 (edited) yes same errors since 24.september , LOTS OF THEM ... and unable to start SQL Server agent Log Name: Application Source: SQLNCLI11.1 Date: 24.9.2018 0:11:45 Event ID: 1 Task Category: None Level: Error Keywords: Classic Description: SQL Server Native Client 11.0: Unable to load sqlnclir11.rll due to either missing file or version mismatch. The application cannot continue. Event Xml: EFS 7.0.12014.0 Windows Server 2012 R2 SQL Server 2014 Edited November 25, 2018 by gabrielk Link to comment Share on other sites More sharing options...
P-Allen 0 Posted December 7, 2018 Share Posted December 7, 2018 (edited) We are experiencing the same problem on servers when upgrading from ESET EFSW 6.5.x to 7.0.12016.0. This happens on all servers with SQL installed. Has occurred with SQL 2012, 2014, and 2016. Running a repair of the SQL native Client does not fix the problem. The only fix we found, and not a good one, is if there is a SQL service pack upgrade available, installing that fixes the problem. Errors in event log every half hour - SQL Server Native Client 11.0: Unable to load sqlnclir11.rll due to either missing file or version mismatch. The application cannot continue. Hopefully ESET will figure this out and implement a fix. Meanwhile we are not pushing out any more upgrades to v7.x on servers. Edited December 7, 2018 by P-Allen Incorrect version noted Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted December 12, 2018 Administrators Share Posted December 12, 2018 The problem is the dll C:\Windows\System32\1033\sqlnclir11.rll is not properly signed. Since ekrn works as a protected service, only properly signed dlls can be loaded in the protected process. If you don't observe any other issues caused by this, please ignore the error. Should it cause any issues, temporarily disable protected service in the HIPS setup and reboot the machine until Microsoft addresses the issue by properly signing the dll. Link to comment Share on other sites More sharing options...
gabrielk 0 Posted December 13, 2018 Share Posted December 13, 2018 Well , it's hard to ignore these errors when there are tons of them flooding the event logs. After applying the SQL Server 2014 Service Pack 3 (KB4022619) the problem is gone i.e. FIXED Download size: 791,1 MB You may need to restart your computer for this update to take effect. Update type: Optional Service Pack 3 for SQL Server 2014 upgraded all SQL Server 2014 instances and components installed through the SQL Server setup. Service Pack 3 can upgrade all editions of SQL Server 2014 to Service Pack 3 level. For customers in need of additional installation options, please visit the Microsoft Download Center and download the Service Pack 3 SQL Server 2014. To learn more about SQL Server 2014 SP3 please visit the Microsoft Support (hxxp://support.microsoft.com) Knowledge Base article KB 4022619. More information: hxxp://support.microsoft.com/kb/4022619 Link to comment Share on other sites More sharing options...
karsayor 8 Posted December 18, 2018 Share Posted December 18, 2018 Hi Unable to install the Service Pack as I have the issue on SQL Server 2016... Marcos, the issue occurs since version 7.0 and not with 6.5, there was a change in ESET that made this dll signing issue visible ? Thanks Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted December 18, 2018 Administrators Share Posted December 18, 2018 Support for protected service was first added in EFSW v7. With protected service enabled, only dlls with a valid signature can be loaded in protected processes. Link to comment Share on other sites More sharing options...
karsayor 8 Posted December 18, 2018 Share Posted December 18, 2018 ok thanks for the explanation, we'll wait for MS to fix the issue. Link to comment Share on other sites More sharing options...
rpremuz 6 Posted January 16, 2019 Share Posted January 16, 2019 (edited) I am also seeing this error on a Windows Server with MS SQL Server 2012 Express LocalDB (ver. 11.4.7469.6) and MS SQL Server 2012 Native Client (ver. 11.4.7001.0) that were installed with MS Azure AD Connect ver. 1.1.888.0. On 12/12/2018 at 10:40 AM, Marcos said: The problem is the dll C:\Windows\System32\1033\sqlnclir11.rll is not properly signed. Since ekrn works as a protected service, only properly signed dlls can be loaded in the protected process. If you don't observe any other issues caused by this, please ignore the error. Should it cause any issues, temporarily disable protected service in the HIPS setup and reboot the machine until Microsoft addresses the issue by properly signing the dll. BTW, sqlnclir11.rll is not a DLL but a RLL file explained here:https://docs.microsoft.com/en-us/sql/relational-databases/native-client/applications/components-of-sql-server-native-client I do not understand why ekrn service, that works as a protected service, needs to load sqlnclir11.rll file. Edited February 19, 2019 by rpremuz clarification Beech Horn 1 Link to comment Share on other sites More sharing options...
merrysmith 0 Posted January 22, 2019 Share Posted January 22, 2019 nice information. Link to comment Share on other sites More sharing options...
Ran Hooper 1 Posted February 7, 2019 Share Posted February 7, 2019 On 12/18/2018 at 6:25 AM, Marcos said: Support for protected service was first added in EFSW v7. With protected service enabled, only dlls with a valid signature can be loaded in protected processes. What's the workaround on this? It's causing client software crashes in one of our environments. Uninstalling ESET off of the server got rid of the above mentioned error and the frequent disconnects. Can we whitelist this process somehow? Beech Horn 1 Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 18, 2019 Share Posted February 18, 2019 So it looks like sqlnclir11.rll is signed, but the certificate expired in 2013. Even the latest version released on 19th January 2018: https://www.microsoft.com/en-us/download/details.aspx?id=50402 has the same sqlnclir11.rll file signed with the same expired certificate. As Microsoft SQL Server is a fairly common application, Microsoft seems to be in no hurry to update the signing of this file, this causes a lot of problems with our applications and we'd quite like everything else to protected as best as possible, please can we have a workaround for Protected Service and this one file? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted February 18, 2019 Administrators Share Posted February 18, 2019 2 minutes ago, Beech Horn said: As Microsoft SQL Server is a fairly common application, Microsoft seems to be in no hurry to update the signing of this file, this causes a lot of problems with our applications and we'd quite like everything else to protected as best as possible, please can we have a workaround for Protected Service and this one file? There is no way to solve it if Microsoft doesn't update the rll file with one with a valid signature except disabling Protected service in the HIPS setup which would enable unsigned dll files to be loaded in ekrn.exe. Of course, that would be a security hole and unnecessary risk so we don't recommend disabling protected service. Mirek S. 1 Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 18, 2019 Share Posted February 18, 2019 1 hour ago, Marcos said: There is no way to solve it if Microsoft doesn't update the rll file with one with a valid signature except disabling Protected service in the HIPS setup which would enable unsigned dll files to be loaded in ekrn.exe. Of course, that would be a security hole and unnecessary risk so we don't recommend disabling protected service. You may wish to warn those enabling HIPS on their system who have "Microsoft SQL Server 2012 Native Client" installed that there is a conflict with Protected Service as it is commonly used. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted February 18, 2019 Administrators Share Posted February 18, 2019 It is not a conflict, the system feature of protected services works as expected and it does what it's supposed to do - prevents files with invalid digital signature from being loaded into protected processes. Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted February 18, 2019 Administrators Share Posted February 18, 2019 You could try disabling automatic exclusions and adding them manually instead. Let us know if the error is no longer reported after rebooting the server. Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 18, 2019 Share Posted February 18, 2019 7 minutes ago, Marcos said: You could try disabling automatic exclusions and adding them manually instead. Let us know if the error is no longer reported after rebooting the server. Using Edit Rules I couldn't see an option for Protected Service. Should I add it under "HIPS" > "Advanced Setup" > "Drivers always allowed to load"? Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted February 18, 2019 Administrators Share Posted February 18, 2019 I meant this setting: However, disabling protected service will disable an important protection service of Windows 10 and an attacker could theoretically inject into ESET's ekrn.exe running under the system account. Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 19, 2019 Share Posted February 19, 2019 13 hours ago, Marcos said: I meant this setting: However, disabling protected service will disable an important protection service of Windows 10 and an attacker could theoretically inject into ESET's ekrn.exe running under the system account. Yes, can see that option however was looking to have that enabled. Asking some software developers they say that only the root certificate should be looked for in terms of expiry. Also that you should check the immediate certificate was valid at the time the timestamp was generated. So using that logic the rll file has been correctly digitally signed and is still valid. They suggested using the DigiCert tool on: https://www.sslsupportdesk.com/how-to-verify-a-digital-code-signing-signature-in-windows/ to make sure the rll is valid, which it shows it is. Are ESET 100% certain this isn't a bug with someone using the logic of website certificates for code signing instead of looking at the nuances? Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 19, 2019 Share Posted February 19, 2019 Microsoft's official advice is to use SignTool.exe which also shows it as being valid: https://docs.microsoft.com/en-us/windows/desktop/seccrypto/using-signtool-to-verify-a-file-signature Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 19, 2019 Share Posted February 19, 2019 (edited) This answer on StackOverflow explains it well: https://stackoverflow.com/a/3428386/179454 Quote Is timestamped code valid after a Code Signing Certificate expires? Microsoft® Authenticode® (Multi-Purpose) allows you to timestamp your signed code. Timestamping ensures that code will not expire when the certificate expires because the browser validates the timestamp. The timestamping service is provided courtesy of VeriSign. If you use the timestamping service when signing code, a hash of your code is sent to VeriSign’s server to record a timestamp for your code. A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired. So it appears to be a bug in the logic of NOD32. Edited February 19, 2019 by Beech Horn Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted February 19, 2019 Administrators Share Posted February 19, 2019 A HIPS developer responded that it's not about signing files in general, otherwise malware authors could buy one and circumvent the system of protected services implemented in Windows 10. PS needs a properly signed dll with a signature that is expected by CI component. A properly signed dll must meet Anti-Malware Services requirements described at https://docs.microsoft.com/en-us/windows/desktop/services/protecting-anti-malware-services- : Anti-malware service signing requirements The user-mode service that needs to be launched as protected must be signed with valid certificates. The service EXE must be page hash signed, and any non-Windows DLLs that get loaded into the service must be also signed with the same certificates. The hash of these certificates must be added into the resource file, which will be linked into the ELAM driver. Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 19, 2019 Share Posted February 19, 2019 (edited) 5 minutes ago, Marcos said: A HIPS developer responded that it's not about signing files in general, otherwise malware authors could buy one and circumvent the system of protected services implemented in Windows 10. PS needs a properly signed dll with a signature that is expected by CI component. A properly signed dll must meet Anti-Malware Services requirements described at https://docs.microsoft.com/en-us/windows/desktop/services/protecting-anti-malware-services- : Anti-malware service signing requirements The user-mode service that needs to be launched as protected must be signed with valid certificates. The service EXE must be page hash signed, and any non-Windows DLLs that get loaded into the service must be also signed with the same certificates. The hash of these certificates must be added into the resource file, which will be linked into the ELAM driver. However that article describes the code of the anti-malware software itself. Here you are scanning a library outside of the anti-malware software. Edited February 19, 2019 by Beech Horn Link to comment Share on other sites More sharing options...
Administrators Marcos 5,394 Posted February 19, 2019 Administrators Share Posted February 19, 2019 Protected service is a part of Anti-Malware Services protection mechanisms. Link to comment Share on other sites More sharing options...
Beech Horn 1 Posted February 19, 2019 Share Posted February 19, 2019 (edited) 2 minutes ago, Marcos said: Protected service is a part of Anti-Malware Services protection mechanisms. Completely agree. But sqlnclir11.rll isn't part of your Anti-Malware services and this is the file in question. Protected Service is used to protect ESET NOD32 itself. Edited February 19, 2019 by Beech Horn Link to comment Share on other sites More sharing options...
Recommended Posts