I am running on Windows Server 2012. I have a service that creates several processes, one of them is a GUI client. The process in high level is as follows:
Service runs a launcher exe
The launcher exe launches an AutoIT compiled exe
The AutoIT compiled exe launches a winform exe
The winform exe does two things:
a. It write a file to the disk on program startup (test.log)
b. It waits for a keyboard press "c" to write a second file to the disk (test2.log)
The AutoIT script does two things:
a. It launches the said winform exe
b. It sleeps for 5 seconds and then send "c" (Send command)
If I start running this chain manually (from step 2) - everything works fine and 2 files are being created. I guess this happens because I have an interactive session (specifically 2) so it's a no brainer here. However, if I run it from the service, everything runs in session 0 (I verified this with ProcessExplorer) but only the first file is being written. Meaning, the keystroke message was not read by the winform exe.
I read about Session 0 isolation which means that user input from other sessions can't interact with programs (services) running in session 0. However, all of the processes mentioned now run in the same session 0. So I'm not sure why my application doesn't get the keyboard strokes? Any workaround for this? Please note that running under a different session is probably not possible, as the server must run without user logged on and as far as I know, you can't launch a session yourself without logging into the system.
Any help is appreciated.
Thanks!
Your service probably runs under Local System or Local Service account (it's always "logged in" in some sense). But you can change this behavior to allow the service running under any specified account with access to the desktop.
Go to menu "Start->Computer->Manage".
In the "Computer Management" window select "Services and Applications->Services".
Find your service and call "Properties" by popup menu.
Open "Log on" tab.
You have 2 options here:
a. Choose "Local System account" radio button and check "Allo&w service to interact with desktop".
b. Choose "This account" and type or "Browse..." the account you need.
Option (b) could make sense if you set up an auto logon on the machine (in this case you may run as Administrator and have an access to the desktop simultaneously).
Option (a) is applicable only if you don't need running as Administrator. Hope it helps.
Im trying to allow another computer in the same network so acces a server I have local on my computer.
As far as I know, this should be administrated in Componentservices (accesing it by running dcomcnfg.exe). I then rightclick on My Computer and click on the Properties option. Then i click on the tab called Standardproperties and then I check "Activate distributed COM on this computer".
Then I go to COM-safety and click on EDIT. But Distrubuted COM is not in that list for me to administer.
What am I missing?
I was wondering if it is possible to use the command window commands to attach to a remote process? (It gets very annoying for remote debugging to roll through the dialog steps every time.)
I don't think there's any way to do what you want from the command line. But you should be able to eliminate at least some of the dialog steps.
For example, for C++, in the Project Properties find the Debugging Tab and change "Debugger to launch" to "Remote Windows Debugger". Now change Remote Command to the name of the process you want to attach to, change Remote Server Name to the relevant host name and change Attach to 'yes'. You can also set other properties as desired.
Press F5 (or Debug | Start) and you should end up attached to the process you identified on the remote server you identified.
I have a application to list all music files in user machine, a "Explorer" button is using to quickly open Windows Explorer and highlight the file in Windows Explorer. I tried ShellExecute, but it doesn't work, the API will launch associate application. Any Windows API can do that? Thanks in advance.
You can simply start explorer.exe with the /select argument, as detailed in this Knowledge Base article:
Explorer /select,C:\TestDir\TestApp.exe
You can create an IE instance and navigate to your folder, then query the IShellBrowser service from the top level browser service and get the active view's IShellView interface. Use IShellView::SelectItem to select items.
Remember to call IWebBrowser::Quit when you don't need the explorer window.
This method can not get around Windows Vista's User Interface Privilege Isolation. If the folder is opened in a process with a different integrity level, a broker IE extension is needed to continue the automation.
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\