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.
I suspect you are wasting a lot of time reinstalling Windows. If you rather debug the actual behaviour I think you might make more progress.
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?
OIC, I thought you mean something else like using WaitForSingleObject function (synchapi.h) - Win32 apps | Microsoft Docs to get more output from Clarion and the templates.
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.
Exactly, but I’m also reminded that if MS cant keep their assets safe it is fair to assume this maybe an OS thing or not.
Lapsus$ hackers leak 37GB of Microsoft’s alleged source code (bleepingcomputer.com)
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.
Odd character… …
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.
I am aware that this update has caused problems with domain servers as noted here CISA Temporarily Removes CVE-2022-26925 from Known Exploited Vulnerability Catalog | CISA
Windows 11 known issues and notifications | Microsoft Docs
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.
Do you run the IDE elevated? If so, do you get any more information if you attempt to run that commandline from an elevated prompt?
Also, might be nice to store the dbgview path in a variable or token.
No, I do this for C7+ IDE’s Microsoft Application Compatibility Toolkit - tweaking apps/manifests - de escalating UAC - ClarionHub
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.
Are you using an absolute path for the call.
My guess is you’re making assumptions about the current folder
Please show us the actual code
So we can help you more effectively
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.
you can see in the image immediately above ( 729b733ec704a544943b708e4a420f867dabe607.png (401×1046) (clarionhub.com)) and in the next image previous to that ( cfd90f2c932baf8caca04c88268842bf1b9187ba.png (1217×738) (clarionhub.com)) what the command line is.
This works when I use #Rundll to call CreateProcess though.
Those are images of prompts, not source code.
I’m still a little fuzzy on why you’re automating the launching of DebugView in the first place
Auditing purposes, there is a window of opportunity for hackers to alter source code before its compiled, so I’m just removing potential attack vectors in order to expose back doors legally.
There’s always more than one way to skin the cat! 
I’m also aware that criminals infect society and they are often the one’s you least expect.
