0

I have a problem with a web service that is installed and started with a .msi that is created with the WiX toolset.

The service can be installed and started on all the machines I tested so far (shown as running in the Services Manager) but on some machines it is not reachable (for example via a browser) and not shown in the list of listening ports on that machine (displayed with 'netstat -a').

I am trying to figure out what's going wrong but I am not really familiar with web service development and configuration. It's a third party service, thus I don't know how it works internally. A good starting point for me would be to find out, what exactly happens when a service is installed and started during the execution of the .msi-file. Maybe I could try to tackle the problem on a lower level then.

Below is my code in the ServiceInstall-Element:

<ServiceInstall
            Id="ServiceID"
            Type="ownProcess"
            Vital="yes"
            Name="ServiceName"
            DisplayName="ServiceDisplayName"
            Description="Lorem Ipsum"
            Start="auto"
            Account="LocalSystem"
            ErrorControl="normal"
            Interactive="no"
            Arguments="action=run">
    </ServiceInstall>

The argument is important - without it, the service won't start or run. Maybe someone else encounterd the same or a similar problem and can help me out.

Thanks already in advance - each hint is appreciated.

EDIT I (15.04.18):

As it might be a problem with the specific service, I will add some further information here:

It's a third party software called CryptoLicensing: http://www.ssware.com/cryptolicensing/cryptolicensing_net.htm

Part of this software is that specific program, that serves as a License Server and does the license registration, for example in a customer's network. The service can be run as a Windows application or installed and run as a Windows service. In both cases it should be listening on a (pre-)specified port on the installed machine. Whenever I start the .exe as an application, everything works as intended. The service is reachable (for example with the browser) and can be accessed from other machines in the network. When the .exe is installed and started as a service, it does not work as intended on every machine. For example if I install and start the service on my laptop, it is shown as running in the Services Manager, but is not reachable on its assigned URL (not even on the localhost) nor is the specific port displayed in the active listening ports, for example with 'netstat -a'. The service itself starts without any error messages and does not log any errors or exceptions as it seems to be running without any problems.

I contacted the vendor, but sometimes he doesn't reply quickly and he is not very specific in his replies.

Before asking the question I assumed that it was a problem with the Windows user rights and the WiX installer but during the discussion here I had the feeling that it might a problem with the service itself. I hope this 'new' piece of information helps in isolating and location the problem.

Thanks to everyone who helped so far!

BeniEnge
  • 1
  • 6
  • This isn't directly an installer problem. You need to profile your program to understand it's dependencies and see what is missing on this one machine. Then decide if it's something the installer can install or if it's something the installer needs to detect and abort if not present. It could also just be a bug in your service that's exposed by the configuration of this one machine. – Christopher Painter Apr 12 '18 at 21:14
  • I thought of that as well. The problem is, the service is not mine. I bought it from a provider (LogicNP, CryptoLicensing) and do not have access to the source code or any information on the internal process. Thus I also can't really debug the service. Do you think it might be good to edit the question and add that information (since it could be a problem related to that special service) or open a new question for that reason? – BeniEnge Apr 15 '18 at 10:13
  • I spent years doing something called "application repackaging". This basically means you take a cra**y third party installer and reverse engineer it into a clean MSI. You have to determine not only what their installer did but what it should have done. I've profiled many services like this where I didn't have the source code to divine what was missing. It can be done even without the source. It's a pain but use things like ProcessMonitor to look for things it's trying to access and failing on. Use Depends or .NET reflector or other tools to learn as much as you can about it. – Christopher Painter Apr 15 '18 at 12:29
  • Has this issue been resolved? If so, maybe add an answer yourself as others could face this particular issue as well? – Stein Åsmul Jun 13 '18 at 10:25
  • No, I am afraid - I am still trying to figure out, what might be the problem. But the communication with the developer takes quite a while. If the issue ever gets resolved, I will add an answer. – BeniEnge Jun 14 '18 at 12:04

3 Answers3

1

Hopefully not stating the obvious here, but WiX doesn't do much except populate the ServiceInstall table in the MSI file, so this is about why Windows Installer won't start the service. ServiceInstall table:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa371637(v=vs.85).aspx

Also, this isn't really about ServiceInstall - it's probably about the ServiceControl element in your WiX source, but it's not clear whether that's how you're starting it or if you're starting it manually later on. That does make a difference. What is the error message and where are you getting it, and is it a 1920 or 1921 error (in the context of ServiceControl).

The main reason a service will start on one system but not another is missing dependencies. If your service is C++ based (the post doesn't say) then there are probably dependencies on C runtimes, UCRT runtimes, MFC or ATL runtimes and so on.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Here's a protip: Set the service control element to not start the service during the install so you can atleast get fully installed. Then try to start the service manually. Profile it... attach a debugger, look for missing files, examine registry access and so on. Servicecontrol just attempts to start the service. It's the service itself that is the problem. – Christopher Painter Apr 12 '18 at 21:17
  • Probably it is not a problem with the WiX installer but rather with the service itself. I can actually install and start the service with the command line Service Control (sc.exe) but the problem remains - even though the service is actually running (visible in the Services Manager) it does not work properly (it's a web service that should be listening on a specific port, but the listening port is not even displayed in the list of active ports with 'netstat -a'). As stated in the comment above, the service is not mine so I cannot debug it. – BeniEnge Apr 15 '18 at 10:19
  • So there is not even any error message displayed - installation and startup of the service go smoothly, the (web) service is just not reachable. As it tends to be a problem with the specific service itself, might it be a good idea to edit the question or even post a new one? – BeniEnge Apr 15 '18 at 10:21
0

First: are you sure this service is intended to run as LocalSystem? (MSDN, SO).

Second: did you check the event logs in detail for anything obvious? If the service is good you should find a hint at least. Something to start with. I find that I sometimes miss the actual logs in the event viewer because it is so "crowded". My take on it: empty the log and stop and restart the service.

Something locking / blocking: If the service installs and runs OK I would suspect other factors such as firewalls (hardware & software), security software in general (anti-virus, malware scanners), network configuration issues (proxies, WINS, DNS and all the complexities involved in networking). Is the service trying to reach an UNC path?

Diverse Machines: What are the target machines? Are they virtual, are they physical, are they test machines, are they operative SOE machines in corporate networks? Are they the same OS version and edition?

Further Ideas: It is not quite related, but maybe skim this list of suggestions for debugging from another answer (I am not sure why it was down-voted, I think it is an OK list to inspire debugging ideas): Windows Application Startup Error Exception code: 0xe0434352 (maybe just skim the bolded words for ideas - Recommended).

sc.exe: And finally, perhaps check the sc.exe tool (Service Control) and see if it can provide you with some useful information for debugging.

Some further links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thanks for the detailed answer! I use LocalSystem because the service did not start when I used any other account. Do you think this could be a cause for the malfunction? And considering the target machines - so far it runs on machines with Windows Server 2008 R2 and Windows 10 (using Parallels Desktop for Mac. The machines on which the service does not run are Windows 7 (Desktop) and Windows 10 (virtual). My guess is, that the problem is related to the user rights somehow - but I am not really an expert in that topic. – BeniEnge Apr 12 '18 at 19:32
  • Just to cover the obvious in case it was missed in "the heat of the battle" :-): Did you review the **event logs** in detail? If the service is good there should be plenty of information there to help you get started debugging. Does the service need a license? – Stein Åsmul Apr 12 '18 at 19:36
  • @BeniEnge The problem machines, are they joined to the domain properly? Virtuals are notorious here. Just checking. Is there a server component to this service installed somewhere? If so, is there a share on that server accessible by UNC? – Stein Åsmul Apr 14 '18 at 00:26
  • The service does not need a license, it also does not log any errors or exceptions as it starts and runs without any (visible) problems. It is just not listening on the port that it's supposed to be and also not displayed in the list of active ports with 'netstat -a'. Please see my other recent comments above, I do not own the source code, so I can't debug the service. And so far I only tested it on the local machine, in the failure case there was no server involved. In the succesful case I installed the service on a server and could access it from within the network (same domain). – BeniEnge Apr 15 '18 at 10:25
0

After almost 20 months we finally (and accidentally) found a solution to the problem! For the few machines, on which the service did not run properly, setting the NoInteractiveServices value in the registry to 0 did the trick. A value of 1 (which is default) means that no service is allowed to run interactively, regardless of whether it has the SERVICE_INTERACTIVE_PROCESS property. More information on Interactive Services.

I am not completely satisfied with the solution, because on all the other machines NoInteractiveServices is set to 1 AND the service runs properly anyway. However, on the machines where the service did not run interactively this solution worked for us. Thus I will accept this as an answer.

If anyone has more information on this issue and can explain why this works, feel free to add them - I would be very interested!

BeniEnge
  • 1
  • 6
  • What do the machines have in common? What OS and version? What security software? Do they have the same version of the service? Etc... [Here is a good service FAQ](https://www.coretechnologies.com/WindowsServices/FAQ.html) - see *"Evolution"* section. – Stein Åsmul Dec 06 '19 at 20:20