Hello Laurent, Regarding Pharo Issue 4910, http://code.google.com/p/pharo/issues/detail?id=4910 Did you see my reply ? Did you get any further ? I would really like to solve this problem. I have described it before, but here is what I think happens: - you start the ZnZincServerAdaptor, which implies creating a listener socket and process - you test it to see if it is running by doing one or more requests - this means that at least one connection and worker process are alive - you save the image - the server receives a shutdown and stops cleanly - since this is a ZnMultiThreadedServer and not the experimental ZnManagingMultiThreadedServer it leaves the connection and the worker process alone - you restart the image - the server receives a startup and starts working - the worker process is revived and will continue its blocking read for the next request - this signals a primitive failed and causes a hang/crash Now, using the lastest Zn, the primitive failed should be caught and the connection and worker should be cleaned up silently, unless there is also a VM problem, but I don't think so. (It would also be possible to make sure that no open connections are alive, close the browser that you used, check the Process Monitor) Another option is to use the experimental ZnManagingMultiThreadedServer which does track its own connections and cleans them up, which should result in the worker processes stopping cleanly. The next code requires the very latest Zinc-Seaside adaptor, you could try: ZnZincServerAdaptor new port: 8080; serverClass: ZnManagingMultiThreadedServer; start; yourself Regards, Sven