Without seeing your source code to look what you are doing, it's difficult to say exactly
what is causing your problem, however you did mentioned above;
I suppose because I used NP_Child True when creating a process which shares data with the my ACON handler code.
There's at least two problems with that sentence.
When creating a process with NP_Child,TRUE the child
ABSOLUTELY MUST exit before the parent can do so,
there needs to be robust exit arbitration put in place by the parent, so this always happens,
See IDOS->WaitForChildExit() and also IDOS->CheckForChildExit(), also the autodoc for IDOS->CreateNewProc()
has several code examples on how to do this on earlier DOS releases.
Secondly, you must not share data with any DOS handler process that does not come in via a dospacket
(or vector port function for new style filesystems)
All DOS handlers must be re-entrant, the same loaded code can be run by multiple processes concurrently,
so the handler process must open any resources itself and delete them on exit itself,
and the handler process is never flagged as an NP_Child when started by DOS.
You can only have READABLE global data that the handler process accesses, and WRITABLE data that is going
to be accessible between processes absolutely must be protected by a semaphore or mutex.
I am not sure why you are creating a process, but DOS takes care of starting up the handlers for you.
This happens automatically when something accesses the device name in the doslist.
Specifically when something calls the IDOS->GetDeviceProc[Flags] function.
So, please check the packet autodocs for ACTION_STARTUP, it will show the handler startup proceedure.
Other than the above, you can run the FSVPTool in SDK:c and look at the start.c function for example
code of starting up a new style filesystem handler, just ignore the vector-port stuff if you are doing
a dospacket based handler.
I hope this helps.