So I have fiddled around with this one too now.
My findings so far:
My main development machine is Win 8.1 Home patched to date, R221, NWjs 0.13.0 beta6
My notebook runs on a Win 7 Pro 64 Bit patched to date, neither C2 nor NW.js installed, I just run compiled NW apps.
Previewing in NW.js works exactly once per project name change.
Why does it work: A new AppData\Local\%username%\%ProjectName% folder structure is created upon execution.
This is of course a tedious workaround as it inflates the appdata folder.
Running the nw.js instances in this way I noticed that they appear as 32bit instances.
Exporting to a built application is the same, HOWEVER, the 64 bit will fire up every time and "just" leave those unpleasant zombie processes behind - which the 32 bit version also does.
The catch:
After having a look in AppData\Local\%username%\%ProjectName%\User Data\ , you will notice some garbage text files there. I call them garbage files because as of now I'm to ignorant to oversee the implications when they're not there
First Run 0 KB - created when the app is run for the first time
lockfile 0 KB - existent while the app is running
Local State 2 KB, some config and statistic tracking going on there
Deleting the First Run won't do anything, deleting the lockfile is prohibited by the running app, but
after removal of the local state - tadaaaa, your NW app will fire up again! Until the next startup... because a new local state will be generated. Same is true if you mess up the Local State (bad syntax etc.). It will dump the old file to Local State.bad and create a fresh one.
That brings me to the conclusion that renaming the project is equivalent to deletion of the Local State file.
Didn't bother to compare the folder structures changes yet, but comparing the to Local State files (after 32 Bit run and 64 Bit run) reveals some differences in the files.
The first is the missing parameter "browser":{"last_redirect_origin":""} in the 32 Bit version.
Second being in the structure info_cache, the "is_using_default_name":false is set to true in the 32 Bit version.
The last noticable difference is the absence of "plugin_stats2":[] in the 32 Bit version.
However, bad news is that filling up the missing, different parameters in the 32 Bit version will not get it to run.
This all is a bit separated from the zombie processes issue, as I can confirm that building an empty project will always close properly (32 or 64 bit).