Related
Starting Visual Studio 2015 also launches two other executables:
VsHub.exe
and
Microsoft.VsHub.Server.HttpHost.exe
Both of these take a considerable space in the task manager.
How can I delete this "Visual Studio Hub" option? I don't use any of Visual Studio 'top-notch' features, including the Visual Studio Hub one.
I thought I’d try to shed some light on the VS Hub and what it’s intended for. I work for Microsoft.
As sraboy mentions, the VS Hub is an out-of-proc services host that Visual Studio (and other VS shell-based products such as Blend) use in order to support multi-tool communication, better responsiveness within devenv (VS), and enable certain services to extend past the lifetime of the spawning process. The set of services currently hosted in the VS Hub includes many of the items called out in the other answers, such as roaming settings, processing of large swaths of ETL data that is rendered in the diagnostics tooling, some telemetry reporting, and extension auto update and notifications. That set of services is very likely to grow in the future though, so even if none of those services seem necessary at the moment, additional services will be hosted there in the future (i.e. it’s a pretty big hammer to disable the vshub.exe through the renaming recommendation :-).
In terms of lifetime, the vshub and host processes (i.e. Microsoft.VsHub.Server.HttpHost(64).exe) can stay running after devenv.exe closes. However, they should not keep running indefinitely. In most cases these processes will terminate within ~5 minutes of the last instance of a VS-based shell closing. So if you have an instance of VS running (devenv.exe) and an instance of Blend running (blend.exe), and you shut down devenv.exe, vshub and the associated host processes will keep running. If you then shut down blend.exe, vshub and the associated host process will still be running. After about 5 minutes from then, however, those additional processes will shut down. If you start another instance of devenv.exe within that 5 minute window, then vshub and the associated host processes will not terminate, and will keep running (basically the host processes terminate whenever they don’t receive any requests within 5 minutes, and after all of the host processes terminate, the vshub.exe process itself terminates).
Resource-wise, the vshub.exe process itself should always be relatively lithe. If it ever gets large, then that’s a bug and I’d love to know about it so we can fix it :-) The host processes, on the other hand, may get very large depending on the service that is being hosted. In particular, the diagnostics tooling works by processing ETL. ETL can be very, very, large, and as such, the host may use a lot of resources. The diagnostics team is looking at ways to reduce that, but for the moment, closing the diagnostics tool window when you don’t need it should help mitigate the problem.
In terms of online connectivity, there are three main sources in the current set of hosted services at the moment (note, this will change over time). First, as user3345048 mentions, the service that detects and auto-updates extensions runs in that process. The options that control that communication are in Tools | Options | Environment | Extensions and Updates (see the first two checkboxes). Second, roaming settings runs as a service in the VS Hub. The setting that controls this behavior is in Tools | Options | Environment | Synchronized settings (or more holistically, if you do not sign into the personalization account in the upper right hand corner of VS). Finally, the VS Hub does report telemetry. The volume of this data can be significantly reduced via the Help | Customer Feedback Options | Settings… menu item. You can also read about the kind of telemetry that Microsoft collects and how it’s used in that location.
Something no one's mentioned above...
According to my firewall log, VsHub.exe, Microsoft.VsHub.Server.HttpHost.exe, and Microsoft.VsHub.Server.HttpHostx64.exe all try to communicate online.
Addresses I saw to which there were outgoing connection attempts included 191.236.194.164 (Microsoft Azure, Wichita Kansas) and 23.102.160.172 (Microsoft Azure, Redmond Washington).
I realize "modern" software is supposed to be cloud-integrated, but...
As one who does not require anything from Microsoft Azure servers, and who is legitimately concerned with privacy and not leaking any part of what I'm working on to the outside world, I'd really like A) to have a way to choose not to run these programs, or B) be provided with settings to limit their chattiness online. Yes, the firewall blocks the connections, but that's a last resort.
Just a simple checkbox, "[ ] Contact Microsoft Azure Servers" would be nice. Whether that would mean not running the programs in question or just having them not make the online connections isn't of consequence to me. I guess from a resource perspective the former would be better as it would use fewer resources.
As a rule I wouldn't propose to change the files in an installed application's suite of files, but as I have a virtual machine environment within which I can test changes to Visual Studio 2015 without much consequence (snapshots are wonderful), I tried altering the permissions (to remove inheritance then disallow Read and Execute for Users) on these three files.
Voila, no more VsHub applications running, trying to contact remote systems.
Visual Studio comes right up. I'm not seeing a downside here.
-Noel
I am using Windows 7 x64 with Visual Studio Express 2015. I have terminated annoying processes with Task Manager. Then I have deleted the C:\Program Files (x86)\Common Files\microsoft shared\VsHub folder. This operation solves the problem, but requires administrator rights.
As xakepp35 mentioned, you can delete the C:\Program Files (x86)\Common Files\microsoft shared\VsHub folder. However, I suspect that updates or other installers will likely try to re-create it.
What I did was shut down all the VS processes. Take ownership of the folder (as admin) and then RAR (ZIP) up the folder and finally delete it (RAR as a backup if I need the files back). Mine is on an SSD so I want to conserve space. Otherwise you could simply rename it and leave it in place.
Then to prevent it being created again, I used an old Win 3.1 trick. Create a text file named VsHub.txt in the C:\Program Files (x86)\Common Files\microsoft shared folder. Then rename the text file and take off the .txt extension leaving a file named VsHub. Since the OS can't create a folder and a file of the same name in the same location, poof, its inaccessible as a folder to VS and its inaccessible and future installers/updaters as a folder either. Then if you need to allow access again in the future, simply add the .txt back on the file and away you go.
This seems to be a communication Swiss Army knife for visual studio as per #sraboy's answer. It is used during debugging to display performance information about the running process, but also to send telemetry to Microsoft about the project you're working on. You can build and step through code fine with it disabled (at first glance).
Removing, renaming or blocking the vshub process creation with AV will break the performance tracing I mentioned. Losing vshub improves privacy while using Visual Studio as it communicates with vortex.data.microsoft.com, passing information such as solution & project GUIDs along with your account id. Below is a screenshot from fiddler intercepting the HTTPS data.
Blocking access at network level helps with privacy, but it will not address your resource usage issue. I would consider the latter as a normal overhead of running Visual Studio.
For your use case, you can probably get away with some form of disabling (blocking instantiation with your antivirus software is probably the cleanest approach), but it may support additional functionality I haven't figured out yet.
For those of you who want to preserve VSHub and still be able to use Fiddler you can setup a Filter in Fiddler with the following setting:
Request Headers > Hide if URL contains =
REGEX:localhost:\d+\/vshub\/
EDIT - you probably want to add this too:
Hosts > Show only the following Hosts: =
localhost;
in order to omit vortex.data.microsoft.com etc.. requests
According to a Microsoft Program Manager commenting on the Visual Studio Blog commenting on the Visual Studio Blog, it's used to support multi-tool communication across the VS suite. Given how complicated Visual Studio is, I wouldn't recommend anything as harsh as xakepp35's answer (deleting it).
On my Win10 x64 with VS2015 running, while debugging, there's three processes and the total RAM usage is less than 150MB total. Unless you're page-thrashing on a machine with minimal RAM that's not much to be concerned about. Given that you're running VS2015, I'd guess you have 150MB to spare.
Until or unless you find documentation showing explicitly what the Hub is supporting, I'd recommend leaving it be. In my experience, Visual Studio installs are far too easy to break.
One of the reasons why Visual Studio tries to connect online seems also that, by default, search online for updates for both Visual Studio and its extensions.
Also, Visual Studio includes a version of Internet Explorer within its core so that webpage (and extension) can be downloaded live. In other words, it acts as a browser as well and as we all know... Microsoft is pretty keen on checking its users' data and usage of its software.
There are plenty of online functions in the menu Tools → Options.
(To be honest, I do prefer MonoDevelop even with its flaws.)
It's needed for BrowserLink, the Diagnostics window, Intellitrace.
I sometimes need these features, but only have 8 GB of RAM. I'm usually at 90-95% usage so I created a batch file to toggle VSHub on and off by renaming the folder and creating a symlink to an empty folder with dummy files.
Shutdown Visual Studio before running.
#echo off
goto CheckVsHubRunning
:KillVsHub
echo Killing VsHub Process
taskkill /IM VsHub.exe /T /F
TIMEOUT /T 3 /NOBREAK
:CheckVsHubRunning
ver > nul
tasklist /FI "IMAGENAME eq VsHub.exe" | find /I /N "VsHub.exe"
if "%ERRORLEVEL%"=="0" goto KillVsHub
if "%ERRORLEVEL%"=="1" echo VsHub is not running.
echo.
PUSHD "C:\Program Files (x86)\Common Files\microsoft shared"
IF NOT EXIST "VsHub.original" (
echo Renaming Original VsHub folder.
RENAME "VsHub" "VsHub.original"
)
IF NOT EXIST "VsHub.dummy" (
echo Creating Dummy Folder and Contents
mkdir "VsHub.dummy"
copy NUL > "VsHub.dummy\1.0.0.0"
copy NUL > "VsHub.dummy\ServiceModules"
mkdir "VsHub.dummy\dummy"
)
IF EXIST "VsHub\dummy" (
echo ENABLING VsHub
echo.
rmdir VsHub
mklink /d VsHub VsHub.original
) ELSE (
echo DISABLING VsHub
echo.
rmdir VsHub
mklink /d VsHub VsHub.dummy
)
echo.
pause
On my machine VSHub and its cronies usually use:
VsHub.exe: 50 MB initially. 250-350 MB after 2+ hrs
Microsoft.VsHub.Server.HttpHost.exe: 200 MB initially. 350+MB after 1+ hrs
Microsoft.VsHub.Server.HttpHostx64.exe: 320 MB initially. 550+MB after 1+ hrs
This frees up over a 1 GB of RAM with hardly any functionality lost.
"VsHub" should be renamed to "SmartMobileCloud";
that's how stupidTrendy it is. I dumped it;
my VisualC editing/debugging wasn't harmed.
After installing VisualStudio, remove unUsed extensions, do the
"C:\Program Files (x86)\Common Files\Microsoft Shared\ - Deleted - VsHub"
fix... and put a "VsHub" text file there ( no ".TXT" ),
so nothing can recreate the folder.
I'm working on a project where the goal is to be able to update a windows computer 100%. That means a program or a script that updates windows automatically with no user interaction at all. Ideally a standalone script that can be run from another script.
The reason: I need to update a lot of computers in my line of work. They can be at any patch level and everything from Windows XP to Windows 8. My goal is to start a script, wait/do something else and then find a fully patched computer.
I've solved a lot by finding ZTIWindowsUpdate.wsf in the MDT Task Sequence.
This can be used like this from an admin cmd:
cssript.exe ZTIWindowsUpdate.wsf
My problem so far is that the computer requires a reboot between some of the updates. Probably because of dependencies. ZTIWindowsUpdate.wsf needs to be run as administrator and i can't seem to find a solution to start it as administrator at reboot. Additionally if I get the script to run on startup, how do I stop it, and how do I know when its time to stop it?
Can someone help med with a foolproof solution to this problem?
Thanks!
Don't need to FULL update a Windows OS, most of the updates are not needed, most updates are not relationated with security and we can survive without they, you need to read the description of each update to understand what changes made. FULLY updating a Windows can be negative point of performance in several scenarios.
All that you need is to download your desired updates, then store it in a folder with this batch script:
#Echo off
For %%# in (*.msu) Do (
Echo: Installing update: %%#
Wusa "%%#" /quiet /norestart
)
Echo Windows Update finished.
Pause&Exit
Also you can compress the folder (the updates + the script) into a Self executable with winrar to distribute it as a standalone file.
Info:
Wusa.exe is the Windows Update commandline application.
The files are processed one by one, not all at once.
The quiet switch makes the installation silent.
The norestart switch don't restart after installing the update even if needed.
If a update is installed in the OS then is not installed again, without getting an error window or stopping the execution of the script.
PS: See Wusa /? for more switches.
I hope this helps.
UPDATE:
Another alternative is to download and install ALL the updates with WSUS utility.
http://download.wsusoffline.net/
The updates for Win7 x64 (for example) are stored here: "...\wsusoffline\client\w61-x64\glb"
PS: The "DoUpdate.cmd" batch file in the "CMD" dir of the application is what you need if need to automate the task in "background".
The simplest solution to the problem you're describing is to get your script to configure automatic logon for the built-in Administrator account, then add itself to the Startup folder. You do need to know (or reset) the Administrator account password to use this option.
There are many other possibilities, some examples are: use a startup script and psexec; use srvany to create a service that runs your script; use task scheduler to schedule your script to run automatically, either interactively or non-interactively; disable WUA, configure automatic logon for the account you're using, and add your script to the Startup folder.
Note that you'll save time and bandwidth if you can set up a WSUS server or (even simpler, and cheaper if you don't already have a Windows server) a transparent caching proxy. However this won't avoid the need to reboot during the update sequence.
You may find my script useful as an alternative starting point to ZTIWindowsUpdate.wsf, if only because it is smaller and simpler to understand.
The moast time consuming thing of a WindowsUpadate procedere is the download of the Setupfiles for the Updates. You should look into a lokaly in the network installed WUS (Window Update Server) and make sure the PC updates from the WUS. If the PCs are all in a ActiveDirectory Domain then the needed settings are very easy to manage. But if not this setting could make a simple batch-script which uses the normal windows update routine.
Another solution would be to make batch-scripts where you install the predownloaded updateFiles with the silent-switch. Allmoast every setup.exe has such a silent switch. If a update isn't needed the update stops for this upload automatically. I'm using such a batch-script wizzardy now for quiet a time now.
PS: If the Computer were from one/your compagny you should "thank" your predecessor for many hours of work to the far future.
PPS: By the way XP and Vista should be phased out. They are now realy old and for XP the already extended supporttime is axed by Microsoft next year and should only used if it is realy realy needed for one small situation where a Windows 7 isn't a solution in any way possible.
To run
cssript.exe ZTIWindowsUpdate.wsf
as Administrator after reboots, you can create a Task in the Task Scheduler with the proper permissions and to run on boot. =]
An automated way is, WuInstall. I'm using it for 1 year now and it's perfect, it actually does what it should. It's a command line tool which automatically searches, downloads and installs the updates. There are several "switches" that let you allow to customize the process. Thanks to the rebootcycle-switch for instance, updating a newly setup PC is done with ease - in one go.
Here's another way ------
Perform instructions below at your own risk:
To automate windows update these instructions may or may not work for your system however it appears to work to an extent for Windows 7 as these instructions were tested on Windows 7.
MUST READ: 1. If the step below does not work verify then you are most likely part of a domain and your security policy may not allow you to perform steps below! 2. UAC prompts were also disabled for the duration of the windows updates so the batch files can run without interruption; be careful to restore this to default when done
Caution this step will make your computer less secure, immediately remove this after your computer is completely up to date. Set a reminder for 24 hours later if need be:
1.
First you will have to make sure your computer automatically logs into a user. You can do this by clicking start menu, type "netplwiz", press enter or open the wizard, under the users tab, select your username, and un-check "require password", type your password, close this window.
2.
Create 3 batch files to start the automated process. (Open notepad paste each code into a separate notepad and perform a save as corresponding_file_name.bat)
One. Save as: any_name.bat then copy this batch file to your startup folder for the user you made auto login. (Click start > All Programs > Startup)
start "" c:\autoupdate1.bat
exit
Two. Save as: autoupdate1.bat then copy this to C:\ drive
wuauclt /detectnow
wuauclt /updatenow
reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" > nul && shutdown -r -t 0
start "" c:\autoupdate2.bat
exit
Three. Save as: autoupdate2.bat then copy this to C:\ drive
ping 127.0.0.1 -n 61 > nul
start "" c:\autoupdate1.bat
exit
Restart or open the batch file in the startup folder and watch the magic begin!
3.
When it is completely done updating just delete the batch files from the startup folder & c:\ drive
Once again follow these instructions at your own risk as it can create an endless loop if you do not know how to stop this process by removing it from the startup folder or going into windows under safe-mode to remove the batch files
Final notes: If you run into issues running the batch files chances are you may have to look up how to disable UAC prompts for your Windows version
I'm having a problem with good ol' bdeadmin.exe in Vista. First, let's get the predictable responses out of the way:
"You should not require your application to be elevated."
This one does. C'est la vie.
"You need to embed a manifest file."
It is already compiled, it is many years old, the company that created it has no intention of doing it again, and it is installed from a Merge Module (MSM file).
"BDE is obsolete, you should be using dbExpress"
One and a half million lines of code. 'Nuff said.
"Drop a manifest file next to the EXE."
Tried that, did nothing. As a test, that same manifest file was able to make several other EXE files require elevation, just not the one I wanted. Something in there is preventing the external manifest from being read.
"Create a shortcut and set SLDF_RUNAS_USER."
Can't do that, it's a Control Panel applet.
The only thing that worked was setting "Run this program as an administrator" under the Compatibility tab of its Properties window. I shouldn't have to tell users to do this. Bad for business. I need to have the installer do this. The MSM file uses a static path.
You can programmatically set the "Run this program as an administrator" flag (the option you find in the Compatibility tab of an EXE's properties), by setting a simple registry key. You need to create a string value (REG_SZ) under one of these keys (if you want the setting to be per user or per machine, respectively):
HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers
or
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers
The name of the value needs to be the full path to your executable (if the path contains spaces, do not surround the path with quotes) and the data of the value must contain the string RUNASADMIN.
For sample:
reg.exe Add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\Program Files\MyApp\Test.exe" /d "PUT__VALUE__HERE"
Compatibility Modes
WIN95 Windows 95
WIN98 Windows 98
WIN4SP5 Windows NT 4.0 SP5
WIN2000 Windows 2000
WINXPSP2 Windows XP SP2
WINXPSP3 Windows XP SP3
VISTARTM Vista
VISTASP1 Vista SP1
VISTASP2 Vista SP2
WIN7RTM Windows 7
WINSRV03SP1 Windows Server 2003 SP1
WINSRV08SP1 Windows Server 2008 SP1
Privilege Level
RUNASADMIN Run program as an administrator
REG ADD "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers" /v
"C:\temp\compatmodel\iconsext.exe" /t REG_SZ /d "WINXPSP3 RUNASADMIN"
/f
References:
http://www.verboon.info/2011/03/running-an-application-as-administrator-or-in-compatibility-mode/
This is a long shot, but if you have the word "setup" or "install" in the name of the EXE, Windows will prompt for elevation when running it. I don't know if that'll work with a control panel applet, though.
Use a wrap program which uses ShellExcute that uses "runas" as its "verb" to run the program you want.
I have found that the .manifest file method doesn't work if the .exe is under C:\Program files\... and the .exe has previously been run without the .manifest file. Windows remembers the .manifest from the first time the .exe is run. This means you can't just send the manifest when users complain that their installations don't run. The manifest file has to be placed before or during the same installation that places the .exe.
Windows rechecks the .manifest if the .exe changes (e.g. new release or different number of bytes)
Have you tried Microsoft's Application Compatibility Toolkit? It analyses your app and provides compatibility shims that might be able to help resolve your problem.
Pack your app into WinRar SFX with silent mode + admin request mode.
Much simpler than messing with .MSI variables.
I'd be surprised if this was possible. It would be an ideal way for malicious code to abuse the system. You're probably going to have tell the user the administrator must install or they must have admin rights (like all the other programs on windows do).
My current project involves deploying an upgraded .exe file that runs as a Windows Service. In order to overwrite the existing .exe with the new version, I currently need to:
Stop the service
Uninstall the service
Reboot the system (so Windows releases it's hold on the file)
Deploy the new .exe
Reinstall the service
Start the upgraded service.
I'd like to avoid the reboot, so that this can be a fully scripted/automated upgrade.
Is there any way to avoid rebooting? Maybe a command-line tool that will force Windows to give up it's death grip on the old .exe?
sc delete "service name"
will delete a service. I find that the sc utility is much easier to locate than digging around for installutil. Remember to stop the service if you have not already.
I had sort of the same problem as you. I have a system service that i want to uninstall and afterwards reinstall as part of an update. On certain systems this would not work without a reboot. The problem was that a call to DeleteService() would return ok, but the following call to CreateService() would tell me the service was still there, but marked for deletion (error code 1072). The registry would reflect that, since the subkey was still there (under HKLM\System\CurrentControlSet\Services), but "DeleteFlag" was set to 1. From that point on, only a reboot could fix the situation.
Some things that don't work:
Using "sc delete": it had the same problems as I. The call would return ok, but the service was not really gone and still in the registry with DeleteFlag = 1.
Deleting the key in the registry. The Service Manager seems to keep a database in memory and the registry is just a copy of it for the next boot.
Adding wait loops, waiting for .exe files to be ready to be overwritten, killing the process, etc.
Closing handles to the service. Which ones??
But here is what worked:
I noticed in some articles here on stackoverflow that net.exe has start/stop features as well (I only knew of sc.exe utility). And strangely enough, a "net stop svcname" plus a "sc delete svcname" worked! So net.exe must do something I don't do.
But net.exe doesn't contain an import to ControlService(), so how does it stop the service? I found out that net.exe spawns net1.exe, but net1.exe doesn't import ControlService() as well. I used the great API Monitor utility ( http://www.rohitab.com/apimonitor ) to see what net1.exe is doing, but it never called anything that looked promising.
But then I saw that it imports NetServiceControl() from NETAPI32.DLL (that had at least "Service" in its name!). MSDN says that this function is obsolete. Nevertheless, I found the prototype in LMSvc.h and some parameter description here: http://cyberkinetica.homeunix.net/os2tk45/srvfpgr/369_L2_NetServiceControlorN.html . When you load NETAPI32.DLL and use NetServiceControl(NULL, service_name, 3, 0, 0) (3 is for SERVICE_CTRL_UNINSTALL, which is used to stop) the service is stopped afterwards. And it can be deleted and reinstalled afterwards without DeleteFlag or reboot!
So it was never a problem of deleting, but of stopping the service properly. And NetServiceControl() does the trick. Sorry for the long post, but I thought it might help someone with similar problems. (Just for reference, I use Win7 SP1 x64.)
Are you not able to stop the service before the update (and restart after the update) using the commands below?
net stop <service name>
net start <service name>
Whenever I'm testing/deploying a service I'm able to upload files without reinstalling as long as the service is stopped. I'm not sure if the issue you are having is different.
If in .net ( I'm not sure if it works for all windows services)
Stop the service (THis may be why you're having a problem.)
InstallUtil -u [name of executable]
Installutil -i [name of executable]
Start the service again...
Unless I'm changing the service's public interface, I often deploy upgraded versions of my services without even unistalling/reinstalling... ALl I do is stop the service, replace the files and restart the service again...
As noted by StingyJack and mcbala, and in reference to comments made by Mike L, my experience is that on a Windows 2000 machine, when uninstalling / reinstalling .Net services, "installutil /u" does require a reboot, even when the service was previously stopped. "sc /delete", on the other hand, does not require a reboot - it deletes the service right away (as long as it is stopped).
I have often wondered, actually, whether there is a good reason "installutil /u" requires a reboot... Is "sc /delete" actually doing something wrong / leaving something hanging?
Both Jonathan and Charles are right... you've got to stop the service first, then uninstall/reinstall. Combining their two answers makes the perfect batch file or PowerShell script.
I will make mention of a caution learned the hard way -- Windows 2000 Server (possibly the client OS as well) will require a reboot before the reinstall no matter what. There must be a registry key that is not fully cleared until the box is rebooted. Windows Server 2003, Windows XP and later OS versions do not suffer that pain.
(so Windows releases it's hold on the
file)
Instead, do Ctrl+Alt+Del right after the Stop of the service and kill the .exe of the service. Than, you can uninstall the service without rebooting. This happened to me in the past and it solves the part that you need to reboot.
Should it be necessary to manually remove a service:
Run Regedit or regedt32.
Find the registry key entry for your service under the following key:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services
Delete the Registry Key
You will have to reboot before the list gets updated in services
I am using the InstallUtil.exe packed with .NET Framework.
The usage to uninstall is: InstallUtil '\path\to\assembly\with\the\installer\classes' /u so for example: installutil MyService.HostService.exe /u
The /u switch stands for uninstall, without it the util performs normal installation of the service. The utility stops the service if it is running and I never had problems with Windows keeping lock on the service files. You can read about other options of InstallUtil on MSDN.
P.S.:if you don't have installutil in your path variable use full path like this: C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe "C:\MyServiceFolder\MyService.HostService.exe" /u or if you need 64bit version it can be found in 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\' .The version number in path varies depending on .NET version.
My batch file to stop and delete service
#echo off
title Service Uninstaller
color 0A
set blank=
set service=blank
:start
echo.&echo.&echo.
SET /P service=Enter the name of the service you want to uninstall:
IF "%service%"=="" (ECHO Nothing is entered
GoTo :start)
cls
echo.&echo.&echo We will delete the service: %service%
ping -n 5 -w 1 127.0.0.1>nul
::net stop %service%
ping -n 2 -w 1 127.0.0.1>nul
sc delete %service%
pause
:end
I have a Windows XP SP2 virtual machine which can be accessed via VNC. It's also running Deep Freeze so there should be no problem in forcing it to reboot. I am looking for a way to force the operating system to reboot instead of shutting down or completely remove the ability to shut down the machine using software applications (such as the usual way from the start menu, the shutdown program or other custom programs).
Thank you,
Tom
Try this:
shutdown /r /t 1 /f
Alex
To remove the ability to shut down then your best bet is to create a group policy for the user/user group and specify that they can only restart the system. I have done this in the past to ensure that only the administrator account can shut down a computer. it has prevented me from mistakenly shutting down a remote pc at 2am in the morning when i meant to re-start it.
In XP there is a DOS command called shutdown. If you type shutdown /? from a command prompt you will see the options available. Using this you can create a Batch file.
Try DShutdown.exe. It's flexible and can do all these things.