I was writing a vbs script to monitor a process and restart it if it died.
however as i was new to vbs i made a mistake in identifying the running process and had a infinate loop of starting a new version and hence crashed my pc....
i have fixed the code to work properly now but in the script properties>script tab the "stop script after specified number of seconds" has been set to 1 and if i disable this option and kick apply.. its still set :( this has only started being like this after i opened a billion cmd consoles and crashed my pc.... is this some sort of security feature.. how do i disable it.
Had exactly the same problem on W7 Ultimate.
The following article was helpful:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/wsh_setindivprops.mspx?mfr=true
"To set global properties for all scripts that are run with the Windows-based script host
1. Click Start, and then click Run.
In the Open box, enter wscript, and then click OK. The Windows Script Host Settings dialog box appears.
Select the Stop script after specified number of seconds check box.
In the seconds box, enter the time limit you want to place on all scripts.
"
Just delete the [scriptname].wsh file in the same directory as the script. Possibly that's been made read-only or similar?
That's the file that contains the settings. You can find more details in this MSDN article: Setting and Customizing Script Properties (.wsh)
Edit: Some new suggestions that might help:
Try going to this key in the registry: HKLM\Software\Microsoft\Windows Script Host\Settings and checking if there is a setting in there that might be the reason. Might be worth going to the same path but under Current User as well (so HKCU\Software\Microsoft\Windows Script Host\Settings).
Otherwise there is an option in the Group Policy Editor called Maximum wait time for Group Policy scripts. I don't think this would affect you but might be worth making sure.
Finally, if neither of the above suggestions help maybe either of the following might at least alleviate the problem:
There is a property called WScript.Timeout which you can set at the beginning of your scripts (like WScript.Timeout = 60) that might help.
There is also a command line parameter \T to wscript that can be used to setting the timeout as described here.
Related
I have made an apple script that takes pictures of people using PhotoBooth. However, every time I open it, it asks for permission to use PhotoBooth instead of instantly taking a photo. I have already set the [Security & Privacy > Privacy > Automation > Allow Script to use PhotoBooth] but it still prompts me every time to allow PhotoBooth. Is there any way to fix this without downloading anything or changing my script? Thanks!
Is your script saved as an applet? While 10.14 remembers previous user-granted permissions, it will re-prompt every time the script changes. Traditional AppleScript applets implement a basic persistence mechanism that saves the current state of the script's top-level variables upon quitting. Discussion here:
https://forum.latenightsw.com/t/mojave-and-applescript-applets/1563/13
One quick trick for avoiding any persistent state:
script MyScript
-- original code goes here…
end script
on run
local tempScript
copy MyScript to tempScript
run tempScript
end run
If you do need to save state (e.g. user preferences) between runs, then you'll either need to code sign the applet or else use an alternate mechanism (e.g. NSUserDefaults via AppleScript-ObjC).
I have the following problem: I've created scheduled jobs that are only containing calls to a cmd and have parameters that contain things like project name etc.
I know about the fact that you have to set it to "Run only when user is logged on" if you want to see the window (cmd in this case) and also have to uncheck "hidden".
Until a week or two ago that worked fine, the box was showing up. Now the exact same job does no longer show the dos box. I suspect a windows update but I couldn't find anything useful in the update history of the server.
Do you guys have any idea what it might be? I tried switching the settings between the two "run as" options, tried setting it to hidden, tried switching "configure for" around...
The jobs run ok most of the time, the output is generated in most cases but if things go wrong I want to see the shell and not have to pipe everything to a .txt :/
I tried looking on google etc for a solution but only found other problems or the "my tasks run hidden if I choose run whether user is logged on or not" solutions.
Any ideas or hints? Anything would be really appreciated!
As you use scheduler to automate running of some rutine task, what's the point of manually checking/controlling it's execution? It is sort of negates benefit of automation and should be done through some basic logging (you can built in in your task scripts or whatever it is) and even viewer where you can check whether your tasks was run successfully.
Why it is required to you to see this window? Are you really need it?
If you state that it used to work OK then check logs does your tasks run successfully all the tine but hidden from you or it's something else?
Try to re-create / create new task & check whether it is not run hidden with settings you use.
From your description your scheduled task indeed configured so that it should be visible, namely:
- It is scheduled under your current logon account.
- It is configured to Run only when user is logged on.
These 2 conditions required for task to be visible.
The Hidden checkbox in the Windows Task Scheduler has nothing to do with how the scheduled program is displayed (in fact, there are no display options for scheduled tasks like there are with shortcuts). The Hidden checkbox controls whether or not the task is displayed in the Task Scheduler. If you set check it, then Task Scheduler will not display it unless the View Hidden Tasks option in the View menu is selected. You should still see the program window when it runs even if it is checked.
You did not indicate what changes you had made to the task between the time it worked and when it stopped, but one change that would prevent the window from being shown is if you had changed the account that runs it to the SYSTEM account. That is a trick that people use to hide the window (which is not a good solution, especially since there are much safer options), so if you had changed that, then you would not see it.
(The OP may have already fixed this by now), but if anyone else has the same problem, check the user account. If the task is not too complicated, you could do as Mikhail suggested and re-create the task from scratch.
I have a vbscript file that must run under 32bit on a 64 bit Windows 7 machine so that it can connect to a 32 bit Access database. From a run box I can enter:
C:\Windows\SysWow64\WSCRIPT.EXE P:\Applicants\Applicants.wsf
and it runs great. When I try to run this as a scheduled task, it runs in under a second (it shouldn't be that fast) and claims it finished successfully. This is the 'action' I am running it under currently:
Start a Program
C:\Windows\SysWow64\WSCRIPT.EXE
Arguments: //Nologo //B P:\Applicants\Applicants.wsf >> P:\Applicants\logfile.txt
I have also tried running it under CScript instead of WScript and the result is exactly the same.
Before I added "//Nologo //B" (a tip I found here) it would start running and never stop.
The optional "Start In" box is empty. If I put any value in it at all (tried P:\Applicants) the task fails to start with "Error Value: 2147942667." No solutions offered by searching this error code have worked so I leave this box empty.
The logfile never even gets created and none of the work the script performs is getting done.
The task runs under my network account and should have access to all needed drives and resources.
Suggestions? Without a logfile I don't even know where to begin troubleshooting this thing.
EDIT: New Info: If I set it to run only when I am logged in it works fine. It is only when set to run even if user is logged off that it doesn't work, even if I am logged in when it runs.
EDIT 2: Security context of 'run even if user is logged off' states that ""...select the radio button labeled Run whether user is logged on or not. If this radio button is selected, tasks will not run interactively. To make a task run interactively, select the Run only when user is logged on radio button."
So I guess it thinks my script is somehow interactive, but it isn't. There aren't any kind of prompts or dialog boxes or msgBox calls so I'm not sure why this would be an issue.
Got it! The problem was that I was referencing a mapped drive with P:\ both in the 'action' call and in the script itself. When I replaced all calls to the P drive with the full network path \server\share everything works fine. Of course mapped drives aren't available if I'm not logged in, makes perfect sense :p
You have two options.
1.Create a batch file with the command to run, then schedule the batch file to run instead of the VBScript file.
2.Run the script file directly, instead of using WScript or CScript.
Sources: http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2general/thread/464a3bb3-3bcd-47a0-ab03-f0b8910f2ed1/
One of my programs seems to be changing the Display Properties > Appearance > Effects > Show window contents while dragging setting to off every few hours.
I'm not sure exactly which program, or when it happens. I have a number of programs that seem like likely culprits - wallpaper rotators, software for multiple monitors, multiple virual desktops and switching, and a few others.
I am just thinking to create a little batch script to run periodically and set the setting back to on.
Does anyone know how to do this in windows? I'm using xp pro sp3.
Thanks!
The best option is to do this programmatically using the supported API. i haven't tested this, but it should do the trick:
SystemParametersInfo(SPI_SETDRAGFULLWINDOWS,
TRUE,
NULL,
SPIF_UPDATEINIFILE | SPIF_SENDCHANGE)
You can use SPI_GETDRAGFULLWINDOWS to see if the the bit has been flipped to avoid unnecessarily triggering a WM_SETTINGCHANGE.
You can use RegMon to find the program that keeps changing your settings. Maybe that's a better start than hacking around it.
There is a simple and effective solution to this problem. In Notepad type the following lines :
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop] "DragFullWindows"="1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects\DragFullWindows] "CheckedValue"=dword:00000001 "UncheckedValue"=dword:00000001
Save the file as "Show Window Contents.reg" Double clicking this file and restarting will cure the problem permanently. Post a message if you find this useful.
Aravind Banerjee
It seems the registry setting which controls that preference is HKCU\Control Panel\Desktop\DragFullWindows. You can read more about it here. However, trying it on my own computer does not register the change right away, so a batch script won't do it. You'll probably have to write a program to manipulate it using SystemParametersInfo(). You can pass it the SPI_SETDRAGFULLWINDOWS parameter. Here's a page explaining it more. Here's a page showing how to call it, albeit not for the same parameter.
I suspect it's kept in the registry - maybe [HKEY_CURRENT_USER\Control Panel\Desktop] - "DragFullWindows"?
It would be easy to flip the registry setting back to "1" every hour or so with a batch file.
I am currently working on a program to immediately clear the list of previously-run-commands which appears in the Windows Start -> Run dialog. The procedure for clearing this list by removing the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU key is well documented; however, before these changes take effect, it seems to be necessary to do one of the following:
Restart the computer
Select Start -> Shut down, and then select Cancel.
Neither of these is ideal for the task I am trying to accomplish: #1 is extremely disruptive to the user, and #2 appears to require additional user interaction.
Does anyone know how to immediately (and programmatically) force a reload of this information without requiring any user interaction, while also minimizing disruption of the user's other activities? I would like for the user's Run history to be cleared out immediately after executing my program, without requiring any further action on their part (such as using the "Shut Down" -> "Cancel" trick in #2 above) or forcing a reboot.
Or, to approach the problem from a different angle: When clicking Start -> Shut Down -> Cancel, Windows Explorer reloads the RunMUI key. Is there a way to force a similar reload without having the user select Shut Down and then Cancel?
Things I have already tried:
Monitoring the explorer.exe status using procmon while selecting Shutdown and then Cancel. I see Explorer writing to the RunMRU key, but have not been able to determine what triggers this.
Numerous Google searches along the lines of "reload runmru without reboot". Most results still recommend method #1 above, although a few suggest #2.
Limited MSDN API examination. The RegFlushKey call appears promising, but I haven't ever used it before, so I don't know if it will apply to registry information cached by different processes.
Any suggestions or other information would be greatly appreciated.
Have you tried ccleaner?
http://www.ccleaner.com/
Not a full answer to your question, but I did find a third way to trigger the clearing of the run command from this article in PC Mag.
Killing explorer.exe and then restarting it will also clear the run list after the registry modification.
I have a nasty hack for you. Show the window programatically, hide it immediately (programatically) and click cancel on it (well, you guessed, programmatically).
You might try looking for the icon cache flush API, or other ones, I wouldn't be too suprised if they had side effects like the one you are looking for.
I've seen instances where it actually works, even the F5 key doesn't work? Try this, ctrl>alt>delete then go to task manager, processes tab...end explorer.exe. Then click on file new task and type explorer.exe, then check...does that work?
Windows XP
Right click on the taskbar
Properties menu option
Start Menu tab
Customize button
Programs pane
Clear List
Click on OK
This calls a Windows API function that refreshes the explorere.exe taskbar process and also clears the list (no need for registry edits).
As far as I know, it relies on the explorer.exe process that hosts the start menu/taskbar/desktop being closed and reopened. There is no "clean" way to do this that I am aware of.
If you really need to do this without user interaction, you need to close all explorer.exe processes and relaunch one.
Here's a rudimentary C# program to do that;
using System.Diagnostics;
Process[] procs = Process.GetProcessesByName("explorer");
foreach (Process proc in procs)
{
proc.Kill();
}
Process.Start("explorer.exe");
Note that this will close all "Windows Explorer" windows open, and may or may not open an additional "Windows Explorer" afterwards.
I just tested that on Windows XP 32bit, and it did indeed clear the Run command cache.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ RunMRU\