Could someone who's done a clean install of Windows 10 tell me what their PATH looks like, please? You can see this by opening a Command Prompt and issuing the command "echo %path%"
I have a problem that a number of programs on my system fail with a popup such as "Perl interpreter has stopped working", and I suspect I have a rogue DLL somewhere along my PATH.
My plan is to write a program that sets the %PATH% variable to the "standard" version, then runs the perl.exe program.
If Perl works, I'll be one big step closer to a solution. If Perl still "stops working" then I'll have to look elsewhere.
C:windowssystem32;C:Windows;C:WindowsSystem32Wbem;C:WindowsSystem32WindowsPowerShellv1.0
C:ProgramDataOracleJavajavapath;C:Program Files (x86)AMD APPinx86_64;C:
Program Files (x86)AMD APPinx86;C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSS
ystem32Wbem;C:WINDOWSSystem32WindowsPowerShellv1.0;C:Program Files (x86)
ATI TechnologiesATI.ACECore-Static;C:Program FilesHewlett-PackardSimplePass
;C:Program FilesCalibre2;C:Program FilesOpenVPNin
Thanks for the anwers. I've now turned an obscure problem into a confusing set of obscure problems.
First off, the PATH doesn't seem to be the source of the problem. I get the same symptoms with my path, and the very simple path above.
In the process of testing the various paths, I wrote a small program in Open Object REXX, to set the path (to the directory where my perl.exe resides) and then to run hello.pl with various paths. They all worked.
Then I wrote a BAT equivalent program, and they all failed.
Then, I opened hello.pl by hand. It always failed.
So, Open Object REXX is setting things up so that perl.exe works. But I have no idea what it might be doing under the covers. I'll ask the Open Object REXX gurus...
Rexx runs as a service so runs under System credentials if I remember correctly.
Try running from a Elevated Command Prompt.
Try changing to the directory the pearl script is in before running it.
I started cmd.exe with "Run as Administrator", but I still couldn't get perl.exe to run (get the ...has stopped working... popup). In fact, I get the popup even if I run perl.exe with no parameters.....
Try running from a Elevated Command Prompt.
Try changing to the directory the pearl script is in before running it.
But I've made an additional discovery. If I invoke the perl.exe from inside a rexx program then it works. But if the rexx program calls a script such as get_iplayer.cmd and that script then calls perl.exe then the perl.exe fails.
So, it seems that it is the Windows Command Processor that is failing, assuming that *.cmd scripts are processed by the Windows Command Processor. That's cmd.exe isn't it?
Anyway, it's getting late (for me, anyway) so I'm going to sleep on this.
Where did you get the version of pearl you are running (link)? Did you install it under Win 10 or waas it installed undr 7 or 8.1 then you did the upgrade to 10?
The perl.exe which is failing was bundled with the get_iplayer program. It isn't "installed" as such, it just exists in the same directory as the get_iplayer code. It is "modified" for use with get_iplayer, so I can't just use a standard perl executable (presumably)Where did you get the version of pearl you are running (link)? Did you install it under Win 10 or waas it installed undr 7 or 8.1 then you did the upgrade to 10?
I installed get_iplayer originally under Windows 7 Ulimate x64, and then migrated to Windows 10 about a week ago.
The perl.exe is dated Sep 9, 2014.
What about uninstalling and reinstalling get_iplayer?
btw: I love Rexx, been using it since the late 70's (main frames) to OS/2 to Windows.
I installed the newer version of get_iplayer as my first attempt at fixing the problem. I should have mentioned that.What about uninstalling and reinstalling get_iplayer?
I'm almost at the point where I can live with this. All I have to do is find the tasks that are generating the "... has stopped working" popups, and see if the trick of running them inside REXX fixes them.
The main problem I foresee is the bunch of 4/5 popups I get on a boot/restart - they all point at "The Windows Command Processor", and that doesn't really tell me what was going on at the time. Still, restarts are pretty rare these days, so it's not causing me a big problem.
