Install Command Successful but no Service is Installed

[terryaney]

I have the following 'standard' service.js code (made some 'ugly' single liners to shorten code snippet).

const serviceConfig = packageJson.serviceConfig ?? {};
const host = serviceConfig.host ?? 'localhost';
const port = serviceConfig.port ?? 7801;

// Define the service
const svc = new Service({
	name: 'KAT Camelot Highcharts Export Server',
	description: 'Highcharts Export Server running as a Windows Service',
	script: path.join(__dirname, 'node_modules', 'highcharts-export-server', 'bin', 'cli.js'),
	nodeOptions: [
		'--harmony',
		'--max_old_space_size=4096'
	],
	env: [
		{ name: "NODE_ENV", value: "production" },
		{ name: "PUPPETEER_CACHE_DIR", value: path.join(__dirname, 'node_modules', '.puppeteer-cache') }
	],
	// Add arguments for host and port
	scriptOptions: `--enableServer true --logToConsole false --logLevel 2 --noLogo true --host ${host} --port ${port}`
});

// Listen for the "install" event, which indicates the service is installed
svc.on('install', () => svc.start() );
svc.on('uninstall', () => console.log('Uninstall complete.  The service exists: ', svc.exists));
svc.on('stop', () => console.log('The service has stopped.'));
svc.on('start', () => console.log('The service has started.'));

if (args.uninstall) svc.uninstall();
else if (args.stop) svc.stop();
else if (args.start) svc.start();
else svc.install();

When I install the service it reports success that the service has started, but it is not present in the Services snap-in, but service commands seem to behave as if all is ok.

Command flow

1. node service.js --install - Reports service is running.
2. telnet 127.0.0.1 10447 - Reports that it is unable to connect (proving that nothing is listening.
3. node service.js --stop - Reports that service stopped.
4. node service.js --start - Reports that service started.
5. node service.js --uninstall - Reports successful uninstall.
6. node service.js --uninstall - Run it a second time and reports that the service can not be found, implying that it was found and running in previous command.

Here are screen shots of the flow:

Things I Tried:

1. I discovered that the exe was not even created in D:\btr.services\HighchartsExportServer\node_modules\highcharts-export-server\bin\daemon, so I granted full permissions to the user logging in to D:\btr.services\HighchartsExportServer\ and then when I ran --install it correctly created the file, but still same results as above.
2. I added svc.on('invalidinstallation', () => console.log('The service was unable to install.')); (after already granting full permissions above) and never received this log.
3. I added svc.on('error', e => console.log('Error:', e.message)); and never recived this log.
4. Reading the code for daemon.js start it looks like I should get some sort of error if I try starting the service via node service.js --start multiple times but I'm not getting any log there. Only the successful 'start' event.
5. I tried setting allowServiceLogon: true (not really understanding what it would accomplish) in my service configuration and it didn't have an effect.

Given this information, any ideas of how to continue my debugging efforts of getting this working?

[coreybutler]

I'd suggest replacing the __dirname from your service config with an absolute path. See the details/explanation. Given everything else you've tried, that seems the most likely culprit.

[terryaney]

Here's Event Viewer after trying to run, after performing step 1 above.

[terryaney]

I'd suggest replacing the __dirname from your service config with an absolute path. See the details/explanation. Given everything else you've tried, that seems the most likely culprit.

Tried this. No luck. Still think something to do with this even with the kernelbase.dll error I pasted here? I've been googling that, will update if I find/resolve anything.

[coreybutler]

Does the app run without node-windows on the impacted system? Also, is this Windows 10, 11, or a server edition? Microsoft has created a lot of problems over the last few weeks for Win 10 users. A quick search suggests some of their updates may manifest in kernelbase.dll errors like the one you're seeing. Does your app attempt to access any hardware on the user system, such as a camera, microphone, etc?

[terryaney]

Well, we are just hosting highcharts-export-server. So, shouldn't be using camera, mic, etc.

Our server is (which I have no control over):

OS Name: Microsoft Windows Server 2019 Standard
Version: 10.0.17763 Build 17763

Executing the same value as Service.script allows the app to run correctly without node-windows.

node node_modules\highcharts-export-server\bin\cli.js --enableServer true --logLevel 4 --host 127.0.0.1 --port 10447 --proxyHost 10.138.171.254 --proxyPort 9191

I discovered a few things in trying to see if I could run highcharts-export-server standalone.

1. When trying to create my node-windows.Service application. If I cloned my repo and ran npm install from within an Administrative terminal, when I then ran node service.js --install to create Windows Service, I didn't see a reported error, but seemed that the node_modules folder created had 'admin only' rights assigned to them and thus node-windows couldn't create/compile the exe into the /bin/daemon folder during installation. I mentioned this above, but if I ran all my git/npm actions in a normal prompt, and only the node service --install in an admin prompt, there did not seem to be problems creating the exe.
2. Another issue was that I needed to pass in a proxy server to highcharts-export-server. So, I updated my Service.scriptOptions to include that as well, you can see this in the wrapperArgs in the following screenshot.

Here are the results from installing my service after the adjusting for these issues:

Questions:

1. Do I need to do anything more with proxy settings? I see a nodeOptions property on Service configuration. Not sure what that is used for.
2. I added a console.log line inside the highcharts-export-server\bin\cli.js file, but it never displayed when I ran my service.js --install even though the path to the file seems correct in the wrapperArgs. Does that seem correct, or would it only display when the service is actually ran?
3. When I simply tried executing the generated katcamelothighchartsexportserver.exe from a terminal, I received:

System.IO.FileLoadException: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

I don't know which runtime this is referring to, but maybe you have some ideas?

4. With above modifications, I am still receiving the event log messages posted above about KERNELBASE.dll.

[coreybutler]

nodeOptions provides a way to pass node flags to the executable. See the options here. Also, you can ditch the --harmony flag. That enabled ES5 code back in node 12/13.

console.log will not output anywhere when run as a service, which is expected. You need to implement your own logger. Most folks write to a file.

The last option is due to an old version of winsw with a modern .NET installation. Unfortunately, I never had time to update to a newer build of winsw. As time progressed, I realized it would be better to create our own wrapper (I prototyped one in Go but never released) than try to continue shoehorning into winsw. So, that is the ultimate plan, but I've not had time to pursue that.

Some of these other issues may be causing the kernelbase.dll. There's not a clear way to tell because that dll is so generic.

If you have any problems with the proxy, most servers respect the HTTP_PROXY environment variable, so you could set it there if you needed to.

Hope that helps.

[terryaney]

Do you think there is anything I should do to try and resolve framework mismatches of winsw? Or you think that error message is a red herring?

[coreybutler]

You could try an older version of .NET to see if it resolves the mismatch warning, but it really shouldn't matter. I don't know what "additional configuration" .NET is looking for.

I wish I had more to offer in the way of troubleshooting. node-windows is very old at this point and edge cases are popping up (especially with how volatile Microsoft has been lately with updates). I'd originally planned to rewrite this project, but we have some ideas around far more robust tooling for creating/building/distributing apps that I think are a better use of the time. That could be a ways down the road though. In the meantime, if you keep running into issues with node-windows (especially if the .NET/winsw mismatch is a blocker), it might be worth looking into a Single Executable App.

[khoale012000]

I think this was an issue with mix match .NET runtime version.

Mixed mode assembly is built against version ‘v2.0.50727′ of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.

Try to update the file /node_modules/node-windows/bin/winsw/winsw.exe.config with the below

<startup useLegacyV2RuntimeActivationPolicy="true">

[terryaney]

@khoale012000 Thanks for the suggestion (and probable solution), but read below for more info.

@coreybutler So I resolved the issue. Bottom line was, I needed updated version of winsw.exe. #47, #338, and PR 268 had me suspecting .NET issues.

Working server:

Failing server (note server info of Windows Server 2019):

So, I believe my options to resolve the problem were:

1. Install .NET 2.0 or .NET 3.5 (didn't try this as I didn't have permission to restart servers and wasn't sure if a restart would be required)
2. Try @khoale012000 suggestion (which I didn't see until the writing of this post)
3. Update winsw.exe (which I did via a fork which has a few more details in the 'Reasons for this Fork' intro.)

After using my forked code/winsw.exe (2.12) it worked.

[terryaney]

One last question. The logonAs configuration property. Is that the credentials that should be used to run the service or credentials used when creating the service?

[nickolasdeluca]

@khoale012000 Thanks for the suggestion (and probable solution), but read below for more info.

@coreybutler So I resolved the issue. Bottom line was, I needed updated version of winsw.exe. #47, #338, and PR 268 had me suspecting .NET issues.

Working server:

Failing server (note server info of Windows Server 2019):

So, I believe my options to resolve the problem were:

1. Install .NET 2.0 or .NET 3.5 (didn't try this as I didn't have permission to restart servers and wasn't sure if a restart would be required)
2. Try @khoale012000 suggestion (which I didn't see until the writing of this post)
3. Update winsw.exe (which I did via a fork which has a few more details in the 'Reasons for this Fork' intro.)

After using my forked code/winsw.exe (2.12) it worked.

Thank you so much for this, I was having the same issues in a Windows Server 2012 R2 Standard, couldn't figure out why the services wouldn't show up.

Switched to your fork and it worked perfectly!

If a major rework is coming in the future, can't we merge this fork's changes as a palliative fix? Since they won't matter in the future, I see no reason why we shouldn't use it meanwhile.