I already tried that here (same configuration Win7+ SL4) both with the online version and a version hosted by my local Lightstreamer server and in those cases the browser did shut gracefully down after a very short while, as you described.

My client looks actually like the SL demo, but there is a substantial difference: I've put together a mechanism that automatically reconnects to the Lightstreamer server in case the connection is lost (basically by attempting a reconnection in a while if the previous connection attempt failed or an existing connection is dropped).

Please look at the file I attached to my first post. I believe that the only object that can keep a connection to a LS server alive is the LSClient class: is that correct?. In my case, I have two instances of LSClient that have strong reference. The one I suspect to be the culprit of the issue is actually alive only on the stack of a "SessionActivitymanager" thread (thread 43 in the report), while the other one is kept alive on another "SessionActivitymanager" thread (thread 45). No other threads - notably, application threads or background threads explicitly spawned by my application - are referencing any LSClient class.

What I imagine is that, for some reason, the fact that two LSClient are actually instanced prevents somehow those threads from shutting down.

Can you confirm this?

Coming to your question
> If not, is there any other sequence of actions that triggers the issue (preferably based on the online demo)?
I have not been able to identify yet a specific sequence of actions. It would seem that establishing a connection to a Lightstreamer server is enough to trigger that behaviour, but I do not have yet a specific sequence.

Please let me know your findings or if you would like me to perform more specific tests.

Thank you,
Emilio

PS
Should this analysis fail to yield results, might I propose to enhance the LSClient class with a "Dispose" or "Shutdown" method which would abort the service threads and release the resources? Or to provide an option to have SL API spawn "background" threads, that do not keep a process alive when exiting?