SQL Server 2025 - Unable to run Python scripts

Question

SQL Server 2025 - Unable to run Python scripts

Peter Bishop 231

I have built a SQL Server 2025 instance and, following the instructions here I have installed and configure R and Python support. R is working fine but when I try to run a simple Python script I get the errors:

EXEC sp_execute_external_script @script=N'import sys; print(sys.version)', @language=N'Python'


Msg 39012, Level 16, State 14, Line 0
Unable to communicate with the runtime for 'Python' seript for request id: 0B10DD48-FDDE-434E-933E-AB2532E2D13E. Check the requirements of 'Python' runtime.
STDERR messages from external script:
Traceback (most recent call last) :
  File "<string>", line 1, in <module>
  File "C:\Program Files\Python310\lib\site-packages\revoscalepy\_init _. py", line 127, in <module>
    from .computecontext.RxInSqlServer import RxInSqlServer
  File "C:\Program Files\Python310\lib\site-packages\revoscalepy\computecontext\RxInSqlServer.py", line 13, in <module>
    import dill
  File "C:\Program Files\Python310\lib\site-packages\dill\_init _. py", line 26, in <module>
    from . dill import (
  File "C:\Program Files\Python310\lib\site-packages\dill\_dill.py", line 171, in <module>
    FileType = get_file_type ('rb', buffering=0)
  File "C:\Program Files\Python310\lib\site-packages\dill\_dill.py", line 164, in get_file_type
    f = open (os.devnull, *args, ** kwargs)
PermissionError: [Errno 13] Permission denied: 'nul'

Can anyone advise what might be causing this error?

Many thanks.

Andriy Klyuchevskyy 0 Reputation points

2025-11-29T12:04:54.4833333+00:00
Hi,

I got exactly same error:

Msg 39012, Level 16, State 14, Line 0

Unable to communicate with the runtime for 'Python' script for request id: 4C5F77D5-7A1F-4B7E-A3B2-BCC1C1141210. Check the requirements of 'Python' runtime.

STDERR messages from external script:

Traceback (most recent call last):

File "<string>", line 1, in <module>

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\revoscalepy_init_.py", line 127, in <module>

from .computecontext.RxInSqlServer import RxInSqlServer

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\revoscalepy\computecontext\RxInSqlServer.py", line 13, in <module>

import dill

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\dill_init_.py", line 26, in <module>

from ._dill import (

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\dill_dill.py", line 171, in <module>

FileType = get_file_type('rb', buffering=0)

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\dill_dill.py", line 164, in get_file_type

STDERR messages from external script:

f = open(os.devnull, *args, **kwargs)

PermissionError: [Errno 13] Permission denied: 'nul'

Completion time: 2025-11-29T04:02:36.3129799-08:00

My configuration: Windows 11, SQL Server 2025 Developer Enterprise edition. I didn't have this issue with SQL Server 2022 Developer edition though.
Peter Bishop 231 Reputation points

2025-11-29T14:08:40.27+00:00

Hi. My fix was to also install the "packaging" module as part of the Python configuration. You may need to re-run the icacls commands to ensure that the accounts have access to the newly-installed module but this certainly fixed the issue for me.

Answer recommended by moderator

2 additional answers

Your answer

Andriy Klyuchevskyy 0 Reputation points

2025-11-29T12:04:54.4833333+00:00

Hi,

I got exactly same error:

Msg 39012, Level 16, State 14, Line 0

Unable to communicate with the runtime for 'Python' script for request id: 4C5F77D5-7A1F-4B7E-A3B2-BCC1C1141210. Check the requirements of 'Python' runtime.

STDERR messages from external script:

Traceback (most recent call last):

File "<string>", line 1, in <module>

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\revoscalepy_init_.py", line 127, in <module>

from .computecontext.RxInSqlServer import RxInSqlServer

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\revoscalepy\computecontext\RxInSqlServer.py", line 13, in <module>

import dill

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\dill_init_.py", line 26, in <module>

from ._dill import (

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\dill_dill.py", line 171, in <module>

FileType = get_file_type('rb', buffering=0)

File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python310_64\lib\site-packages\dill_dill.py", line 164, in get_file_type

STDERR messages from external script:

f = open(os.devnull, *args, **kwargs)

PermissionError: [Errno 13] Permission denied: 'nul'

Completion time: 2025-11-29T04:02:36.3129799-08:00

My configuration: Windows 11, SQL Server 2025 Developer Enterprise edition. I didn't have this issue with SQL Server 2022 Developer edition though.
Peter Bishop 231 Reputation points

2025-11-29T14:08:40.27+00:00

Hi. My fix was to also install the "packaging" module as part of the Python configuration. You may need to re-run the icacls commands to ensure that the accounts have access to the newly-installed module but this certainly fixed the issue for me.

Answer 1

Peter Bishop 231

Solved it!

Side-by-side install made no difference so I added some debugging code to "_dill.py" to report the path of "os.devnull" at the point of execution.

On SQL2019, this returned:

Path: C:\ProgramData\SQL2019_PROD\Temp-PY\Appcontainer1\0EE985FD-F669-434F-88D6-1D7C365240E6\nulldeviceout.txt

However, on SQL2025, this returned:

Path: nul

I added similar debug code into "revoscalepy__ init __.py" and that returned the path (above) for the 2019 instance but nothing for the 2025 instance. So I expanded the exception handler (listed in my earlier "Enabling execution in AppContainer" code inclusion comment) to include:

    except Exception as e:
        if hasattr(e, 'message'):
            print(e.message)
        else:
            print(e)
		os.devnull = oldnulldevice

and this reported that the "packaging" module was missing!

So I installed that:

python -m pip install -t "C:\Program Files\Python310\Lib\site-packages" packaging

and re-ran the icacls and Register commands (just in case) and that solved the problem!

Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-11-29T14:09:11.2233333+00:00

Excellent! Great work!

In my case, I already had Python 3.10 in place, and I had downloaded the Revoscalepy stuff some years earlier when I tried to add Python to my SQL 2022 instance (which failed because of a bug with named instances), so possibly I already had this packages module since this attempt. On the other hand, when I search for Packages, under site-packages, I find the module with dates from Thursday. When I made my installation, I ran the steps from Greg's article, since I was unsure of the status. I also updated the pip module itself, while I was at it. Maybe that was the winning play?

I have converted your post to an answer, and also recommended it as the Answer, since you are not able to accept your own posts as the Answer.
Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-11-29T22:08:22.79+00:00

I was curious, so I decided to try installing Python support on a machine which did not already have Python.

First I was brave and tried Python 3.14, but it failed with an an error about not being able to locate the "real C:\Program Files\Python314\Python.exe".

I then tried Python 3.10 and I got exactly the error about nul. Installing packaging and re-running icacls and Register solved the issue.

I get the impression that something has changed over the years so that when https://learn.microsoft.com/en-us/sql/machine-learning/install/sql-machine-learning-services-windows-install-sql-2022 originally was written, there was no need to install packaging separately, but it came with something else.
Peter Bishop 231 Reputation points

2025-11-29T22:21:32.4733333+00:00

Agreed. I've submitted a documentation update request on the main Microsoft article so it's at least mentioned in there.
Andriy Klyuchevskyy 0 Reputation points

2025-11-29T23:48:28.0166667+00:00

Worked for me as well. Thank you so much!
Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-11-30T10:15:53.9333333+00:00

Thanks for submitting the documentation update, Peter! I did not have the confidence to do it myself.
Peter Bishop 231 Reputation points

2025-11-30T10:29:27.3866667+00:00

Ha ha :-) I couldn't find a comments link for Dr Greg's page to get it added in there - which is a shame 'cos that's a much better doco. Maybe I should suggest those fixes to the Microsoft page in the same way.
Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-11-30T10:39:02.1033333+00:00

I'll get in touch with Greg and alert him about this thread.
Peter Bishop 231 Reputation points

2025-11-30T10:40:20.0766667+00:00

Excellent
Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-12-01T22:17:52.2466667+00:00

Greg has updated his post now: https://blog.greglow.com/2025/12/01/fix-getting-r-and-python-to-actually-work-on-sql-server-2022-and-2025/
Peter Bishop 231 Reputation points

2025-12-01T22:40:28.19+00:00

Many thanks for chasing that. And the change has been accepted for the Microsoft documentation.

Answer 2

The error you are encountering when trying to run Python scripts in SQL Server 2025 indicates a permission issue related to accessing the nul device. This can occur if the Launchpad service account does not have the necessary permissions to access certain system resources.

Here are a few steps you can take to troubleshoot and potentially resolve this issue:

Check Launchpad Service Account Permissions: Ensure that the account running the SQL Server Launchpad service has the necessary permissions. The account should have the following rights:
- Log on as a service (SeServiceLogonRight)
- Replace a process-level token (SeAssignPrimaryTokenPrivilege)
- Bypass traverse checking (SeChangeNotifyPrivilege)
- Adjust memory quotas for a process (SeIncreaseQuotaSizePrivilege)
Verify SQLRUserGroup Permissions: Make sure that the SQLRUserGroup has the right to log on locally. If this group has had its rights modified or revoked, it may prevent the Launchpad from executing Python scripts.
Antivirus Software: Check if any antivirus software is locking the folders or files that the Python script is trying to access. Antivirus software can sometimes interfere with script execution.
Configuration Settings: Open SQL Server Configuration Manager and verify that the Launchpad service is running and configured correctly. Ensure that the necessary network protocols (like TCP/IP and Named Pipes) are enabled.
Python Environment: Ensure that the Python environment is set up correctly and that the required packages (like dill) are installed and accessible to the SQL Server instance.

If these steps do not resolve the issue, consider reviewing the SQL Server logs for more detailed error messages that might provide additional insights into the problem.

References:

Answer 3

Erland Sommarskog 128.7K MVP Volunteer Moderator

Sorry for not responding earlier, but I was at PASS in Seattle last week, and this week I've been suffering from jet lag.

I tried adding Python to my fresh SQL 2025 instance, following the instructions in Greg's article. (Except that I already had Python 3.10 installed.) And everything seems to work for me. I ran the below with success on my first attempt.

Really what could be wrong in your case, I don't know. But I said to myself, are we supposed to arrive at that line at all or not?

So I open the Python file and found:

def get_file_type(*args, **kwargs):
    open = kwargs.pop("open", __builtin__.open)
    f = open(os.devnull, *args, **kwargs)
    t = type(f)
    f.close()
    return t

I added the silly line

   x = yyy

before the call to open, and re-ran my SQL script. This time it kept looping without completing. But pressing the red button and looking in the Messages tag, I found an error message about the undefined variable yyy. Ergo: When I run my Python script from SQL Server, I arrive here. Thus, the issue could be the permission on os.devnull. Although, I am more inclined to think that args or kwargs has some funky value in your case.

This was the SQL script that worked for me:

EXEC sp_configure 'external scripts enabled', 1
RECONFIGURE
go
USE tempdb
go
-- Set up table for first example.
DROP TABLE IF EXISTS Playdata
CREATE TABLE Playdata (id   int            NOT NULL,
                       txt  nvarchar(200)  NULL,
     CONSTRAINT pk_Playdata PRIMARY KEY (id)
)
INSERT Playdata(id, txt)
   VALUES (1, N'1,2,3,4'),
          (2, N'Adam, Betty,  Charlie'),
          (3, N'XV, LXI,VII,MCM'),
          (4, N'This, is, perfect'),
          (5, N'No comma in this text'),
          (6, N'ABC,,DDD,, F,, XYZ')
go
-- Set up Python script for replacements.
DECLARE @python_script nvarchar(MAX) = N'
import re, pandas                          # Import package for regexps and pandas.
Data["txt"] = pandas.Series([              # Python/Pandas mumbo-jumbo. :-)
      re.sub(r",\s*(\w)", r", \1", str)    # This is where substituion happens.
      for str in Data["txt"]])
'
-- Run script to get data back. 
EXEC sp_execute_external_script @language = N'Python', -- Set language.
     @input_data_1 = N'SELECT id, txt FROM Playdata',  -- Data sent to Python.
     @input_data_1_name = N'Data',           -- Name of Python variable for input.
     @output_data_1_name = N'Data',          -- Name of Python variable for output.
     @script = @python_script
EXEC sp_execute_external_script @language = N'Python',
     @script = N'import sys;print(sys.version)'

Peter Bishop 231 Reputation points

2025-11-28T14:48:49.9933333+00:00

Hi. No worries on the "delay". I'm not expecting you to fix all my issues but I appreciate it when you can.

I tried the script that you sent and unfortunately it still failed with the same error. I've compared the permissions on NULL for a SQL Server 2019 (working) and SQL Server 2025 (not working) instance and they are the same. I've also tried a second install on a new build server and the results are the same.

The "get_file_type" code of the "_dill.py" files on each server are the same so I can only imagine that something is happening during the installation under SQL2019 (either the SQL Server installation or the relevant supporting CAB files) that isn't happening under SQL 2025.

Will keep digging. Thanks again.
Peter Bishop 231 Reputation points

2025-11-28T15:08:13.4033333+00:00
I added some code to "_dill.py" to dump out the "**kwargs" values and this returned:

key value --- ----- buffering 0

When I tried the same on my SQL 2019 instance I got:

buffering: 0 buffering: -1 buffering: -1 buffering: -1 buffering: -1 buffering: -1 open: <function open at 0x000001F75FCB7598> buffering: -1 open: <function open at 0x000001F75FCB7598> buffering: -1 open: <function open at 0x000001F75FCB7598> buffering: -1 open: <function open at 0x000001F75FCB7598>

So the initial call has the same value but there are obviously no further calls to the "get_file_type" function on the 2025 instance dur to the failure
Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-11-28T16:08:52.7566667+00:00

Since the parameters for the call that fails is the same on both versions, this suggests that the core of the matter is indeed some permission issue. Keep in mind that is the permissions for the account NT Service\MSSQLLAUNCHPAD (for a default instance).

Do you have SQL 2019 and SQL 2025 on the same machine?

If they are on different machines, it is the same operating systems? I ran my test on Windows 11.

Since my Python is very rudimentary, can you share the code to dump args and kwargs, so I can test on my machine?
Peter Bishop 231 Reputation points

2025-11-28T17:11:19.3966667+00:00
The code I pinched was:

for key, value in kwargs.items(): print(f"{key}: {value}")

I put this at the start of the function.

My SQL2019 and SQL2025 instances are on different servers, so I can at least isolate this to a SQL2025 "issue".

I've compared all the permissions through Local Security Policy and they're identical.

I've also compared the permissions assigned to the NULL device and again, they match exactly.

Finally I've checked that the Launchpad service is a member of the same groups and, once again, it is.
Peter Bishop 231 Reputation points

2025-11-28T17:37:03.35+00:00

I've also changed the Launchpad service to run as the local administrator and that made no difference - same error

Peter Bishop 231

Looking at __ init.py __ I can see the following code, which appears to be redirecting devnull to a file:

################################################
# Enabling execution in AppContainer Environment for SQL PYTHON SERVICES
#
# This piece of code should be done before trying to import dill
################################################
if platform.system() == 'Windows' and os.getenv("HOMEPATH") is not None:
    oldnulldevice = os.devnull
    os.devnull = os.path.join(os.environ.get("HOMEPATH"), "nulldeviceout.txt")
    try:
        nulhandle = open(os.devnull, "w+")
        from .utils.RxUtils import _rx_is_appcontainer_enabled, _rx_is_in_sql
        if not _rx_is_appcontainer_enabled() or not _rx_is_in_sql():
            os.devnull = oldnulldevice
        del _rx_is_appcontainer_enabled, _rx_is_in_sql
        nulhandle.close()
    except Exception as e:
        os.devnull = oldnulldevice
################################################

I can see that the "nulldeviceout.txt" file is being created successfully (both in the filesystem - temporarily - and in Process Monitor), so it's not even the actual NULL device that is the issue.

Erland Sommarskog 128.7K MVP Volunteer Moderator

I added this code to get_file_type:

    for key, value in kwargs.items():
        print(f"{key}: {value}")
    print(os.devnull)
    print(*args)

I got this output:

STDOUT messages from external script: 
buffering: 0
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
rb
buffering: -1
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
r
buffering: -1
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
r+b
buffering: -1
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
rb
buffering: -1
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
wb
buffering: -1
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
r
buffering: -1
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
r+b
buffering: -1
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
rb
buffering: -1
STDOUT messages from external script: 
C:\ProgramData\XXV\Temp-PY\Appcontainer1\DD09CC11-5D70-4981-A0DA-7E57DC3867E3\nulldeviceout.txt
wb

I would assume that you get something similar, except that it stops earlier because of the error.

I should mention that the XXV in my path is the name of my SQL Server 2025 instance.

If there is indeed a permission issue, don't forget to grant permissions to ALL APPLICATION PACKAGES.

Peter Bishop 231 Reputation points

2025-11-28T19:37:42.7733333+00:00

Comparing Process Monitor output between the 2019 and 2025 boxes, the entries relating to "nulldeviceout.txt" are the same (including the same result value) except that the 2019 box returns multiple occurrences, similar to the multiple calls to get_file_type.

I may spin up a SQL2022 instance on a new box to see if the same thing happens on a clean server and whether this is unique to 2025.
Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-11-28T19:44:44.4733333+00:00

Is this a named instance or a default instance? As I said, my instance is a named instance.

In SQL 2022, there was an issue where you could not install Python or R on a name instance, because files ended up in different places. I believe this was fixed in a CU. So if you are testing with SQL 2022, apply CU22 before you test.

Although, the issue may not be related to SQL 2025 as such, but rather there could be some differences between the machines.
Peter Bishop 231 Reputation points

2025-11-28T21:18:27.71+00:00

Tried a SQL2022 install on a fresh server with the same result.
Erland Sommarskog 128.7K Reputation points MVP Volunteer Moderator

2025-11-29T08:43:35.9366667+00:00

Since it works on my machines, I'm inclined to think that this is something in your environment. (As I mentioned I have SQL 2025 on Windows 11. On the other hand, the SQL 2022 instance where I have the ML extensions installed runs on Windows Server 2022.)

I assume that the fresh servers you have, all come from the same tailored image, which has some setting causing problems here. Whereas the SQL 2019 machine is from an older image.

You could try installing a named instance of SQL 2025 on the SQL 2019 machine, but I understand that if this is a production server that you don't want to do that.

But you could also try to install SQL 2019 on a fresh server. Now there is a difference here, since SQL 2019 ships with Python 3.4 (very old an dusty). If the built-in Python works, there is still one more test to do, and that is to add Python 3.10 as an external language. Or even better, a recent version of Python. 3.10 is also an old and unsupported version these days, I believe.
Peter Bishop 231 Reputation points

2025-11-29T11:17:40.61+00:00

Thanks again. The OS of the 2019 and 2025 servers are from the same image, so that's not the root cause. Also I have 2025 instances from different OS builds exhibiting the same problem (all Windows Server 2022, however).

I'll give the 2025 install on the 2019 server a try and see if the problem still occurs - probably not given your experience. I'll also try a newer version of Python as that may do it more easily - I did try this when i first installed the instance and had lots of errors but might try an in-place upgrade instead.

Might have a fun weekend :-)

Share via

SQL Server 2025 - Unable to run Python scripts

2 additional answers

Your answer