You Must Install A Windows Service Pack That Contains A Newer

[Alayna Rother]

Duringthe deployment of an application I am receiving the error code 0x64D

This installation package cannot be installed by the Windows Installer service. You must install a Windows service pack that contains a newer version of the Windows Installer service

According to the error report, it seems that the version of Windows installer is low. We could go into cmd(command prompt) or the run dialog (Windows + R) and execute msiexec -? , and it will open a window containing our version at the top. Could we know what the OS version is for this client?

If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

So we've produced a windows service to feed data to our client application and everything is going great. The client has come up with a fun configuration request that requires two instances of this service running on the same server and configured to point at separate databases.

I've set up the project that contains the windows service, we'll call it AppService from now on, and the ProjectInstaller.cs file that handles custom installation steps to set the service name based on a key in the App.config like so:

The first way was to simply install the first copy of the service, copy the installed directory and renamed it, and then ran the following command after modifying the app config to change the desired service name:

When that didn't work I tried to create a second installer project, edited the config file and built the second installer. When I ran the installer it worked fine but the service did not show up in services.msc so I ran the previous command against the second installed code base.

Sorry for the long winded post, wanted to make sure there is enough relevant information. The piece that so far has me stumped is that it states that the installation of the service completes successfully and its only after it goes to create the EventLog source that the NullReferenceException seems to get thrown. So if anyone knows what I'm doing wrong or has a better approach it would be much appreciated.

I didn't have much luck with the above methods when using our automated deployment software to frequently install/uninstall side-by-side windows services, but I eventually came up with the following which allows me to pass in a parameter to specify a suffix to the service name on the command line. It also allows the designer to function properly and could easily be adapted to override the entire name if necessary.

This will create the service with the name "Awesome Service - UAT". We've used this to run DEVINT, TESTING and ACCEPTANCE versions of the same service running side-by-side on a single machine. Each version has its own set of files/configs - I haven't tried this to install multiple services pointing at the same set of files.

What I've done to make this work is to store the service name and display name in an app.config for my service. Then in my installer class, I load the app.config as an XmlDocument and use xpath to get the values out and apply them to ServiceInstaller.ServiceName and ServiceInstaller.DisplayName, before calling InitializeComponent(). This assumes you're not already setting these properties in InitializeComponent(), in which case, the settings from your config file will be ignored. The following code is what I'm calling from my installer class constructor, before InitializeComponent():

I don't believe reading the configuration file directly from ConfigurationManager.AppSettings or something similar will work as when the installer runs, it's run in the context of InstallUtil.exe, not your service's .exe. You may be able to do something with ConfigurationManager.OpenExeConfiguration, however in my case, this didn't work as I was trying to get at a custom configuration section that was not loaded.

I had a similar situation, where i to needed have a previous service, and an updated service running side by side on the same server. (It was more than just a database change, it was code changes as well). So I couldn't just run the same .exe twice. I needed a new .exe that was compiled with new DLLs but from the same project. Just changing the service name and display name of the service did not work for me, I still received the "service already existed error" which I believe is because I am using a Deployment Project. What finally did work for me is within my Deployment Project Properties there is a property called "ProductCode" which is a Guid.

I keep getting this message on the target machine: "This installation package cannot be installed by the Windows Installer service. You must install a windows service pack that contains a newer version of the Windows Installer service."

Until there is an actual service installer, you need to run Duplicati.WindowsService.exe as an extra later step after an initial install (e.g. from .msi) that does NOT do the automatic or manual start (which is the tray icon).

By default the tray icon contains a Duplicati server, and it can also open the web browser to connect to that. When running as a Windows service, you probably want either no tray icon or run it with --no-hosted-server.

Service is more trouble now, and requires editing Windows shortcuts, e.g. on the desktop and login autorun. Sysinternals Autoruns or Google can help find it, and you can edit the desktop shortcut directly by right-click. One problem is the next Duplicati install from .msi will write over your custom shortcut, but you can rename it.

_System.IO.IOException: The process cannot access the file because another process has locked a portion of the file. at System.IO._Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.ReadCore(Byte[] buffer, Int32 offset, Int32 count) at System.IO.FileStream.Read(Byte[] array, Int32 offset, Int32 count) at Duplicati.Library.Main.Blockprocessor.Readblock() at Duplicati.Library.Main.Operation.BackupHandler.ProcessStream(Stream stream, CompressionHint hint, BackendManager backend, FileBackedStringList blocklisthashes, FileBackedStringList hashcollector, Boolean skipfilehash) at Duplicati.Library.Main.Operation.BackupHandler.HandleFilesystemEntry(ISnapshotService snapshot, BackendManager backend, String path, FileAttributes attributes)

First thing to check would be snapshot-policy which defaults to off and has multiple versions of enable. Locked file, errors on outlook.pst has some discussion on the finer points of figuring out which setting you want to use.

Migrating from User to Service install on Windows (and elsewhere) has discussion about various service issues, however it sounds like you might not be heading there immediately, so maybe you can migrate when/if needed.

I have installed several other custom .Net windows services successfully. A new one I had recently written was very similar to the others and while it installed without error - on starting it with the service controller it failed to start with the error dialog: System error 2 ... system cannot find the file specified.

After time and consternation, the only thing I could think of that was significantly different about this service was that the path and executable name were at least 10 characters longer than any of my other services. On shortening both the path and .exe name and re-installing, the service ran fine: no error! I can only assume my previous path or service or .exe name was too long.

Also, It would be pertinent to mention I had used some borrowed "service driver" code built in to my exe to handle the install/uninstall of the service to the service controller via win API calls. It could be a character limit was hidden within that service driver module.

I could not find any windows related docs to confirm if there is a system bound character limit to a path or service name that I had exceeded. I will dig in to the service driver when time permits and see if that turns out to be the problem. Meanwhile I welcome any insights.

In my case, the problem was caused by a mistake in the service start routine. DriverEntry (in my case it was a kernel-mode driver) returns a bad status value. I think this situation applies to user mode too.

Another possible reason that the sys file is blocked. If your driver doesn't exit clearly (for example, you forget to clean up Device, Callouts etc), the sys file may be blocked. To check that you can try removing sys file when service is not working. Normally you should be able to do so. If not, the driver may hold some resources and in turn blocks the sys file.

If your service indeed blocks the file, you should set the service start to Manual (check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName\Start flag: 0 - start on boot, 3 - manual) and restart your device. This will free up the sys file and you can try again until you fix your clean-up flow.

Well, there is a path limit but not sure the char limit at this movement.Also the the file name should match exe name.sc create MyWinService BinPath=C:\System32\Queue\MyWinService.exe

@bfhd's answer will work if you just want to change the Display Name (which is what's shown in the list in Services.msc, but is not the "real" service name (which is the name of the registry key containing the service information, and used in APIs like OpenService). The Remarks section of this MSDN article talks about service names vs. display names a bit more.

Unfortunately, there's no official way to change a service's name. However, it is probably possible, if you absolutely must rename the service instead of just re-installing it under the new name for some reason. Do the following:

If you must do this programmatically, there may exist a function RegRenameKey that can do the fourth step above for you. I stress may exist because, so far as I can tell, this function is completely unofficial; it's not in MSDN and there's precious little info about it. The only thing I found, other than the Windows headers (which have the prototype, and indicate that it's only on Vista - NT6.0 - and newer), is a Sysinternals forum post, which indicates that it calls an NT syscall (also undocumented). The function prototype, from WinReg.h, is

3a8082e126