I was calling Drive\Path\debugview.exe from #Run a few weeks ago and now its stopped working a couple days a go.
Now the help docs say
#RUN Launches the named program.
program A string constant containing the name of the program to execute, including any command line parameters.
No mention if path should be used, just that its got to be a string constant. Mike suggests it can handle a path here Actual Installer product - #8 by Mike_Duglas but the only way I can get it to work is with an exe name that can be found using the system environment variable PATH=
So thats limited to things like Notepad and taskkill in the windows and windows\system32 folders.
My string constant was a template symbol and called #Run(%Runcommand) and it worked a few weeks ago, but now it doesnt and something has changed on this machine which might give me a clue what has changed because I know its possible to use group policy to restrict apps & users access to folders, to prevent traversal to folders and others things like that to local down a machine which can be very annoying if used maliciously.
The problem is #Run doesnt give any feedback so I’ve had to put createprocessA into a dll and use %Runcommand with the #RunDll createProcessA , so I know its not the %Runcommand playing up because that works with the #RunDll createProcessA.
I’ve also built feedback into the createProcessA dll to give me the windows errorcodes so that I can tell whats going on with the computer if there is a problem.
But the help doc doesnt really state if it should be able to use path or not, its vague and with this computer messing around like it is, some parts of the help docs create a situation that leaves people and programs open to criminal exploitation.
yes, #Run can work with a path. (I just tested it here’).
the most likely explanation to your issue is that the thing you are passing to #RUN does not exist.
I recommend debugging this using #ERROR to just push the stuff you are passing to #Run into the error pad. as in #ERROR(whatever) #RUN(whatever)
That way you can inspect the value, and see if the exe exists in that location - I expect a spelling error etc.
Ok I think this dev machine has been hacked despite all the windows 10 security switched on to the max, because #Run worked a few weeks ago with a path/to/exe and now it doesnt but #Run(%exefilename) found in the windows PATH statement does work.
Time to wipe and start again. I must have the world record for the number of times I keep wiping my computers and reinstalling them, but if malware can be embedded in the chips, like I’ve previously found then maybe its time to call it quits.
So how would you debug the #Run template command then?
I’m already calling debugview using #RunDll to see what the template symbol is before its called by #Run and the template symbol works with createprocess called from #Rundll.
Like I’ve said, the only way I can get #Run to work is if its an exe that can be found in the Window Path statement.
I prefer #ERROR to #RunDLL, but frankly either would work fine. Templates are also great because you can typically inject actual debugging code into the output to see what the template is doing. In most cases that’s all I do - although it doesn’t work well for code happening outside of output, and for that I then use #ERROR .
So, first I’d do a #ERROR before the #RUN line to inspect the whole string being sent to #RUN. Then I’d try and execute that line “as is” from a command prompt, where it’s not in the program folder. so go to some random folder in CMD, and simply paste in the #RUN parameter and see what happens.
What exactly do you mean by this?
Are you talking using Assert(expression) as a template expression or something else?
It works from the dos window (CMD), this is the weird thing about it, it worked fine until a few weeks ago and has now stopped altogether working with any path before the filename.
The only time I can get #run to work is to use an exe filename where the exe resides in a folder found in the windows system environment path, eg PATH=%SystemRoot%\system32;%SystemRoot%;
I do have a few folders to clarion folders added to the path but these are programs outside of the PATH= environment variable.
something else. What I mean is that the template is typically creating output. So something like say; #FOR(%Control) %Control{prop:hide} = true #ENDFOR
So, the #FOR and #ENDFOR are template language statements, and the line inbetween will appear in the output. But I can put anything I like in the output, so ! Bruce : Procedure=%Procedure, Proceduretemplate=%ProcedureTemplate etc #FOR(%Control) %Control{prop:hide} = true #ENDFOR
Now the bruce line appears in the output (the CLW being generated) above the Control lines.
Perhaps you can post the #RUN command (and parameters list?) here so we can see what you are trying?
I think its more a security or environment issue, but the help docs were vague and I need clarification to make sure I wasnt going mad, because I had it working and now it doesnt. I know MS is using Hyper-V to control the computer more and I didnt know just how much more they are controlling virtual pc’s using VMware. Not so long ago you couldnt have hyper-V running on the same machine as VMware, but now you can so there is some sort of integration that has taken place between the two, I suspect what I am seeing is a sort of bleedthrough of windows 10 exploit protection settings into virtual windows machine’s with older OS’s. Its only a guess though.
It’s hard for you to do proper debugging, when you can attribute everything you see to Windows being hacked. Now you might be hacked, or you might now, but I’m not sure how, or why, a hacker would target Clarion’s #RUN function.
Unfortunately if you assume the OS is bad, then it’s hard for you to explore other areas where there might be bugs, perhaps in the IDE, perhaps in your code.
Not so long ago I posted some code on here for createprocessA, maybe thats why?
By #Run no longer working, I’m forced (ie a behaviour change) to use what I’ve written.
I may be getting the wrong end of the stick here, but when I have tried to use run, I have had issues with the file name sent to the run command from clarion. So if a user has an add charictor in a file path that can be found using Windows explorer etc, the path sent to run fails and charictors like , - need to be enclosed on quotes in the clarion string. I had to write code to reset strings.
There’s no special characters in my instance. I can use #Run(‘notepad.exe’) because notepad is in the Path=%SystemRoot% but I cant use #Run(‘c:\subfolder\filename.exe’) this is why I needed to clarify the help docs because it doesnt mention anything about a path being used.
However #Run(‘c:\subfolder\filename.exe’) was working two weeks ago!
Since then I’ve had a windows update but I havent rolled back that update to see if its the problem.
Now I dont know if other things are broken in the update, but the fact #Run(‘c:\subfolder\filename.exe’) has stopped working in the last couple of weeks maybe more than coincidence, but I’ve not seen anyone else reporting this sort of command line problem.
Does ProcMon show any errors? Are there any spaces in your file/path name? If so, I wonder if it would behave any differently if surrounded by double quotes?
Havent used procmon but will check that out thanks, its not spaces in the filepath though that need wrapping in double quotes, the folder and filename are all within 8.3 confines. Its a weird one yet it works perfectly fine if I pass the same to a dll that calls create process.
It might be a security issue, because createprocess has more options for starting an exe.
Edit you can see here the command line appears to be all ok.
It is because some people may not use Debugview but Debugview++ and because both dont do what I want, I’m going to be writing my own version to add the features both of the above are missing, but I dont know what the legality will be for it, so I dont know if I will be able to release it and profit from it.
Using an absolute path, ie c:\folder\filename.exe so even if its called by a program running in a different subfolder, the absolute path should still work.
