hi everyone,

have an annoying issue with one of the programs. Program is a 64bit application running on Win10.
Normally it runs 24/7 and and it works great.

Due to recent policies, windows is locked when user is not at the machine.
This is not a problem, application keeps on running with screen locked.

But if the user is switched, program stops responding and this is not desired.
Worse, even after user is switched back, application does not resume.... it must be aborted and restarted.

What could be the problem or solution? challenge is that i don't really have access to it (it is very remote, i only get access occasionally to machine and not as admin). Any suggestions?

 

hi everyone,

have an annoying issue with one of the programs. Program is a 64bit application running on Win10.
Normally it runs 24/7 and and it works great.

Due to recent policies, windows is locked when user is not at the machine.
This is not a problem, application keeps on running with screen locked.

But if the user is switched, program stops responding and this is not desired.
Worse, even after user is switched back, application does not resume.... it must be aborted and restarted.

What could be the problem or solution? challenge is that i don't really have access to it (it is very remote, i only get access occasionally to machine and not as admin). Any suggestions?

I doubt there's much that you can do unless you own or can access the source code and build the app. It is possible to examine the frozen app with special tools to see what its doing but that's not trivial. Is the app old? how old? The reason I ask is that beginning with Vista the OS manages a concept called "sessions" very differently and an app written for a pre-vista version of Windows might encounter problems with sessions being switched, this is just a suspicion though.

 

This sounds more like an OS problem than an application level problem.

Possible solution: Install XP on a spare computer?

 

application is recent (about a year or so old). i do have access to source code (VS2019).
what would be the special tools? this is running on Win10-64, not sure how installing XP on a spare computer would help. i guess it should be able to run on XP64 if latest DotNET framework can be installed.

 

hi everyone,

have an annoying issue with one of the programs. Program is a 64bit application running on Win10.
Normally it runs 24/7 and and it works great.

Due to recent policies, windows is locked when user is not at the machine.
This is not a problem, application keeps on running with screen locked.

But if the user is switched, program stops responding and this is not desired.
Worse, even after user is switched back, application does not resume.... it must be aborted and restarted.

What could be the problem or solution? challenge is that i don't really have access to it (it is very remote, i only get access occasionally to machine and not as admin). Any suggestions?

I advise you STRONGLY to never lock your computer with Windoze. Windoze security model is dangerous. It can wipe out your profile and suddenly your system won't even boot to anything but a black screen (will act dead). If you are having problems with computer behavior due to utilizing windows security- back your stuff up and STOP using their locking feature.

Windows 10 is dangerous.

 

application is recent (about a year or so old). i do have access to source code (VS2019).
what would be the special tools? this is running on Win10-64, not sure how installing XP on a spare computer would help. i guess it should be able to run on XP64 if latest DotNET framework can be installed.

Tools are probably Process Explorer, I think this will let you see what the threads of a process are doing, what they are waiting on and so on but its cryptic and requires some familiarity with OS internals.

Possibly also Process Monitor might be used to shed light on what takes place when you switch users, again this can be cryptic and time consuming.

Of course you could also just start Visual Studio 2019 and try to attach the debugger to the problem process too, that might be very informative.

If you can get back into Windows and the app is running but unresponsive, attaching the debugger is the first thing I'd try, once you do that you can see all threads and their stacks and possibly get some idea what's being waited on, perhaps a deadlock or something?

Process Explorer and Process Monitor are non-invasive whereas the VS debugger interferes with the app somewhat.

Do you know if the app is designed to react to a user being switched? is there code in there for that? does it look at this for example?

 

the lock policy is something that they changed recently and i am simply exploring if and what could be done to make them happy.

again this is not on my machine, it is on a pc owned and managed by someone else. i cannot dictate what OS should run there or what corporate policies they enforce. and ... well... don't mind me for not going on a crusade telling companies how to run their business or to forget about Win10 and go back to some expired OS... like it or not, Win3x, Win9x, XP, Vista, Win2k etc are all dead, Win10 is in and that's it...

btw application connects/interacts with number of things using different protocols.
for communication with one of the partner nodes, in uses built in TCP server (the other device is a TCP client). i guess changing roles here would be a challenge... maybe have something working as an intermediate node (create separate service running as server).

just followed the link and it looks like that just could be the root of the problem...

SystemEvents.SessionSwitch Event: "System event notifications are not supported under the current context. Server processes, for example, might not support global system event notifications."

i'm thinking about check if the server thread is running or not, and if needed restart it...

will try to see if remote debug will work, i have not tried it and while there are some limitations, that looks like path worth exploring.

 

This is expected behavior. When unlocking with a different user, you also are swapping the user memory space. The old memory containing the running program is swapped out, any previously running programs are either terminated or placed in suspension and the new user space is initialized.


Windows is not intended to be a multi-user OS. So the behavior you observe is the intended behavior.

 

the lock policy is something that they changed recently and i am simply exploring if and what could be done to make them happy.

again this is not on my machine, it is on a pc owned and managed by someone else. i cannot dictate what OS should run there or what corporate policies they enforce. and ... well... don't mind me for not going on a crusade telling companies how to run their business or to forget about Win10 and go back to some expired OS... like it or not, Win3x, Win9x, XP, Vista, Win2k etc are all dead, Win10 is in and that's it...

btw application connects/interacts with number of things using different protocols.
for communication with one of the partner nodes, in uses built in TCP server (the other device is a TCP client). i guess changing roles here would be a challenge... maybe have something working as an intermediate node (create separate service running as server).

just followed the link and it looks like that just could be the root of the problem...

SystemEvents.SessionSwitch Event: "System event notifications are not supported under the current context. Server processes, for example, might not support global system event notifications."

i'm thinking about check if the server thread is running or not, and if needed restart it...

will try to see if remote debug will work, i have not tried it and while there are some limitations, that looks like path worth exploring.

Perhaps you could rewrite the parts that need to persist to run as a service and not in a particular user account.

 

i guess so as well... now i am adding performance counters to try to confirm if that is really the case .

 

after some more digging, it's been determined that this coincides with updates pushed by IT, more specifically with command gpupdate /force

will continue next week and see what comes out next and if it can be handled gracefully without much rewriting...

 

it is solved....

today i modified TCP server code. a bit of polishing is still left to make things pretty but the essential part is done and it works without a hitch... thanks all who chimed in...

 

it is solved....

today i modified TCP server code. a bit of polishing is still left to make things pretty but the essential part is done and it works without a hitch... thanks all who chimed in...

What sort of changes did you make?

 

datagram is long and complex, parsing, alarm handling etc. was all done in a multithreaded setting that was hard to work with. i did not want to go through whole code so i tried to break it down and isolate server itself from all the processing. to that i wrapped everything into a single method, placed it into another thread and just transferred entire received string from server to it. this worked but still caused the same issue as UI would freeze every time gpupdate was called. sometimes this would be a brief thing, but sometimes would take 20 seconds or much longer which was unacceptable. but this split made testing easier and replacing one TCP server for another much simpler. after testing some ten examples i found one that was working through without an issue. no glitches or deadlocks or lost connections, just smooth data flow...