Same as on Linux of Mac 
If the cmd started a process in a sub-shell, the sub-shell will continue. If it didn't, the process will die.
I think the question is does Death give it some notice so it can self decease cleanly or does He just swing the scythe without warning?
Ctrl-C certainly does normally cleanly close Node.js apps. This Issue discusses some of the ins and outs:
Yes, but the specific issue is if Windows decides to reboot, presumably it closes the terminal window cleanly, but does that close node red cleanly?
That should also cleanly shut things down. As I said, the only time it wouldn't cleanly close is if you had a blue-screen error where the whole OS has abruptly terminated.
But from that discussion, it was clear that there are some edge cases.
Just to update on this - I have added the filename to the error message should it happen again.
As for how we are writing the file - it writes to a temporary file and then, only once that temporary file has been written, renames the file. On the face of it, that should protect against corrupt/half-written files from our side. Even if the node process was killed abruptly, the OS will have either renamed the context file or not. The 'real' file will never be left with half-written data in it.
1 Like
That might indicate a more fundamental issue with the device then I think? Possibly an issue with the disk/ssd which could cause those kinds of issues I think.
Is there anything I can share to help out?
Any windows logs or Node red logs?
For this, I don't think anything would appear in the node-red logs. Worth checking the Windows Event logs though. However, they can make for rather scary reading as it is common to find them full of all sorts of strange and inexplicable errors 
Given that there are plenty of us running Node-RED on Windows I imagine that this will be a one-off. The density of data on a modern computer is so high that a random thermal or a stray cosmic ray can easily cause a one-off unexplained error.
You might clean out your event logs though and monitor them for a few days to see if there are any recurring errors.
I have had to delete my global.json a second time now as node-red crashed and I could not get back in i.e. it would not start again, until I deleted the file.
I wonder if my SSD HDD is deteriorating. However I haven’t seen any other issues in Window 10.
Any idea how I could test to see what the root cause is?
Did you check the event logs?
There are also a few SSD test utilities out there if you think one might be a problem. Though honestly, most SSD's are very reliable these days. Unless you push them at max utilisation. As with any drive, it is best to look to expand your storage once you get over 80% or so because by that time, you are getting increasing fragmentation issues (SSD's don't care about fragmentation of files but it starts to cause excessive read/writes) and the drive cannot wear-level so easily. Check out the drive manufacturer and see if they have any utilities.
Not entirely sure what I'm looking for, but I found this and interestingly I don't remember rebooting my PC.... once I have everything on uibuilder I'll move prod to my lovely little Pi4 
and maybe this will be a thing of the past.
I'm running node-red as a service now using the PM2 method here...
Let's see if that fixes it.
ok, so I think the problem has evolved.... Node-RED has been starting nicely. I setup PM2 to run it as a service, however I noticed about 2 weeks ago that data is no longer being stored to disc i.e. each time I restart Node-RED all my history seems to have vanished.
I have tried slightly different context storage options, however this should not be the issue as writing to disc was working fine for at least a couple of months...
I'm going to uninstall node-red and then completely reinstall it in the hope that it fixes the problem, but thought I'd bring it up in case there is a bug somewhere in there.
Over 1 hour later, I did a complete uninstall of NR (including renaming the node-red folder) and then reinstall and then all the rest (too many things to list) to get me back up and running.
When I restart flows the variables remain in tact. As soon as I stop the NR service and restart it, I lose all my history data.
I'm at a loss. Any ideas?
PS: I'm using this setting, which is the original setting I was using...
Got to go to bed, but I'm wondering if contextStorage only works on global variables. The data I'm testing is in flow variables...
By that do you mean that it is working for you with global but not for flow?
Stop node red and start it again in a terminal. It shows the context store(s) in operation in the startup log.
If that is not showing the localfilesystem then did you edit the correct settings file? It tells you which one it is using in the startup log.
Thanks. I'll test that.
I have not confirmed that it works for globals. It was a late night thought.
I can't see what it tells me that I don't already know.... Context Store is the localfilesystem as per the lines I uncommented in the settings.js file.
Can you think of any other tests that I can perform?
so is there anything now in the c:\users\ubuquitous\.node-red\context directory ?
(simple flow below just in case you need one to write something)
[{"id":"474a7c88.3a0434","type":"inject","z":"3e6448b5.f21398","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":190,"y":1000,"wires":[["e1f097d2.8ce758"]]},{"id":"e1f097d2.8ce758","type":"function","z":"3e6448b5.f21398","name":"","func":"flow.set(\"flowfoo\",\"flowbar\");\nglobal.set(\"globalfoo\",\"globalbar\");\ncontext.set(\"nodefoo\",\"nodebar\")\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","x":380,"y":1000,"wires":[[]]}]
yes, there are files and they seem to have current timestamps...
I feel like I must be doing something stoopid here, as it worked before and now it doesn't.
I'll check your flow now @dceejay
