3

Microsoft's maintains a list of bad DLLS. This is one item on that list (emphasis mine)

UMPPC*.DLL and SCRIPTCONTROL*.DLL

These DLL files are loaded in to the address space of SQL Server related processes if you enable the Additional User Mode Data prevention setting for CrowdStrike Anti-Virus/Endpoint protection programs. You might notice failures while SQL Server Agent attempts to create new processes when executing jobs. You might encounter failures while attempting to launch SQL Server Management Studio. You might also see that SQL Server fails to launch SQLDumper.exe to generate memory dumps. We recommend you contact Crowdstrike support with information related to your issue and ask if a fix is available.

I am on a SQL Server 2019 box and I have many of these UMPPC*.DLL and SCRIPTCONTROL*.DLL files. I am considering using SQL Server Agent to fire some SSISDB packages. However, I am not sure how to check if these DLLs are causing problems. This gives me my question: What exact error messages do UMPPC.DLL and SCRIPTCONTROL.DLL cause to appear in SQL Server Agent when it fires SSISDB packages?

1 Answer 1

5

Microsoft's maintains a list of bad DLLS.

To let you know, I've been one of the authors of that page. The dlls on the page aren't particularly nefarious on purpose, but they cause a multitude of issues due to how and why they operate. Due to this they've caused many incidents which seem by most people to be product issues though they are not, unless of course you mean an issue with the security product 😂 There are versions of the security software that work, some that don't. It's hit or miss and I find it quite odd to use a security product that itself uses the same techniques as the items it's guarding you against in order to keep things secure.

I guess if things don't work then it stays secure. /s

What exact error messages do UMPPC.DLL and SCRIPTCONTROL.DLL cause to appear in SQL Server Agent when it fires SSISDB packages?

You can get varying random errors, it depends on where the issue occurs. Mostly it'll be in the job output that it wasn't able to start the application.

I am considering using SQL Server Agent to fire some SSISDB packages. However, I am not sure how to check if these DLLs are causing problems.

You'll know when your jobs don't seem to run properly. When you start to investigate you'll notice that applications aren't properly executing, applications are throwing seemingly random errors, and much of it won't make much sense. There isn't one or any "exact message(s)".

For example, attempting to run items that might talk to the ML services:

Unable to communicate with the runtime for 'R' script for request id: {GUID}. Please check the requirements of 'R' runtime.

Nowhere would that point you to the security software loading these in process. However, once you do the requisite digging, you'll find that it stops the ML processes from starting by detouring certain API calls.

One last item is that they don't just affect SQL Agent. They affect any running process on the server. Period. It can (and has/does) cause issues with the database engine and any other items on the server.

1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.