"Import functions" fails with "Could not activate Python COM server, hr = -2147023541"

[bjrnfrdnnd]

This refers to issue #764.

I got xlwings to work after installing python32 and pointing the interpreters to this 32 bit installation of python (Anaconda, user installation, no admin rights)

xlwings worked then for a week.
Now it stopped working with the same error as in issue #764.
I uninstalled my Anaconda pythons (32 and 64 bit) and reinstalled only the python32 version. No change.
This time, the problem is even weirder: I can run in debug mode and from the commandline (or pycharm) - no problem, everything works.
The only thing which does not work - and the only thing of importance for a production module - is when I switch from debug mode to no-debug mode. Then, when I hit the "import functions" button of the xlwings ribbon, the error message pops up. When not hitting this button, the error message displays in a cell when running a udf.

I again traced this back to the call to my local python installation:
The last unsuccessful call was in function Py() in xlwings.xlam Main module. Line:
If 0 <> XLPyDLLActivateAuto(Py, XLPyCommand, 1) Then Err.Raise 1000, Description:=Py
Py() was called from sub ImportPythonUDFs() in xlwings.xlam Main Module, line
tempPath = Py.Str(Py.Call(Py.Module("xlwings"), "import_udfs", Py.Tuple(GetUdfModules, ActiveWorkbook)))

which was called from Sub ImportFunctions(control As IRibbonControl) in xlwings.xlam Main Module, line
ImportPythonUDFs

The variable XLPyCommand
is

c:\local\Anaconda3_32\pythonw.exe -B -c "import sys, os;sys.path.extend(os.path.normcase(os.path.expandvars(r'C:\local\df\df;')).split(';'));import xlwings.server; xlwings.server.serve('$(CLSID)')"

(no line breaks in the actual variable)

But, actually, the program never executes the call to python (I checked by changing the string and writing to a file).

I am completely at a loss here.
What can I do?

[bjrnfrdnnd]

Update on this issue: The error has gone away again. I can import functions in no-debug mode. I have not the slightest idea what might have changed. I did not change anything between the point in time where it did not work (two days ago) and today.
Should I leave this issue open?

[fzumstein]

Just to clarify: the issue has nothing to do with 32 vs 64 bit. xlwings can cope with all combinations of bitness between OS, Excel and Python as it runs out of process.
"Something" seems to be going on on your system. It's hard to judge what it would be, but if it comes back, maybe a reinstallation/repairing of MS Office would help. I am closing the issue for now, feel free to reopen later if you need to.

[Damrio]

Morning,
First of all, since this is my first comment on this project : warm thanks to the team and contributors as I am a very happy user of this library :)

This post is the closest from what I currently experience (e.g. erratic functioning of UDF functions) so I thought I would add my comment to it even if closed.

I currently have the following issue:

• I was using XLwings functions for over a year, without issues.
• However since last week I got an error when running UDF functions or pressing the "Import Function" button of the add-in, and since then am not able anymore to use UDF functions. Error message is the following:

Note that:

• Currently I still have Runpython() functions running properly
• Excel settings (e.g. Macro Trust center and reference) are in principle correct ; I have checked them again since I have the issue.

My configuration is the following:

• Windows 10, Excel 2016
• Winpython (using Python3.6), in which I upgraded XLwings to its latest version (12.1)

The only things from that configuration that recently changed are:

• an Excel security update
• I upgraded XLwings to its latest version once I saw I was having issues

Note that I did download the udf.xlsm example from the Xlwings website. This example did not work (same error as the picture above), except (very weirdly) for a brief amount of time (I have no idea why, and when I rebooted my laptop it started to misfunction again). The Fibonnacci example does work without issues. So I guess the issue is really coming from the UDF functions.

Further investigations have led me to notice:

• that the macro was having issues at the same stage as mentioned in the post above (e.g. at code line: If 0 <> XLPyDLLActivateAuto(Py, XLPyCommand, 1) Then Err.Raise 1000, Description:=Py)
• The Loadlibrary function seems to be the reason of this failure
• I have tried to run the command displayed in the error message above, in an independent console. When doing this, the code actually works and the xlwings server is started...

Any help appreciated.
Kind thanks.

[Damrio]

Afternoon,
Just to mention that, like @bjrnfrdnnd, I finally was able to recover to a normal operating mode.

This article suggested that spaces in the Python path might generate issues, so I moved my Winpython folder to the root of my laptop (e.g. C:/winpython/...). This was enough to do the trick.

[fzumstein]

thanks for feedback and link! I'll open a separate issue to investigate spaces in the python path.

[dziczekwedrowniczek]

same issue. Don't have any spaces in python interpreter. any ideas?

[fzumstein]

@dziczekwedrowniczek can you please open a new issue and paste your Traceback.

[talalvas]

Afternoon,
Just to mention that, like @bjrnfrdnnd, I finally was able to recover to a normal operating mode.

This article suggested that spaces in the Python path might generate issues, so I moved my Winpython folder to the root of my laptop (e.g. C:/winpython/...). This was enough to do the trick.

I really think this solution should be emphasized and maybe consider to catch this exception when it happens and tell the users that this is exactly what they should do.
The vast majority of users has Python installed in 'Program Files' or 'Program Files (x86)' folder and this error will raise for most of them.
I'm not a contributor to this project and I really don't understand the level of complexity that involved in doing such a bug fix, but I know it took me ages to understand that this is the solution for my problem.
A very simple test can check if the INTERPRETER path has spaces and raise a warning message to the user indicates it may cause problems.
Specially that in previous versions of xlwings this was not an issue and everything worked well even if the interpreter path had spaces.

Thank you very much for this solution @Damrio!

[fzumstein]

thanks @talalvas for bumping this, I'see if I can push #974 sometime soon