mgn0528
March 7th, 2005, 11:24 AM
Hi,
We're having an issue with a client and our software and accessing PC's using remote desktop. Here's what's happening:
Our product is written in VB6 and it uses an in-house ActiveX control to connect to and screen scrape information from a Passport 3270 emulator connected to and IBM Mainframe.
For support, our company uses a web-based remote control application to connect and control the PC's in question. In order to connect the client must start a web session from the PC that we're connecting to. The client is accessing those PC's via remote desktop and then starting IE to make the web connection.
All of this works fine. The issue arrises later in the day after we've connected and done what we need to and after the client has disconnected the remote desktop session.
After a while the application looses the ability to communicate with the emulator and the emulator cannot maintain its conection to the host and an application freeze-up insues. As soon as the client uses remote desktop, or logs back in directly at the terminal everything "wakes up" and starts connecting and communicating.
Now, just thinking about it this behavior is expected. After all we're starting and/or running an application under a specific logon. Then after a while the session timeout and locks the workstation. Since this application does not run as a serice, I assume that Windows can't be sure that this program has permission to run anymore and blocks its threads from running until the user that started the program logs back in. We experienced this same issue with some in-house systems and concluded that remote desktop was the problem and could verify it. it only happened after we had remote desktopped in then closed the session and didn't log back in to the PC. Usually after several hours.
We're programmers, so we don't know exactly how all the network stuff works and we can't be technically sure that this is the absolute cause. I guess that ultimately we're wanting to know more about this behavior... is it by design? is it unique to VB6? COM? Is there a way around this? Are we doing something wrong?
Any insite that anyone might have on this would be greatly appreciated. Thanks!
We're having an issue with a client and our software and accessing PC's using remote desktop. Here's what's happening:
Our product is written in VB6 and it uses an in-house ActiveX control to connect to and screen scrape information from a Passport 3270 emulator connected to and IBM Mainframe.
For support, our company uses a web-based remote control application to connect and control the PC's in question. In order to connect the client must start a web session from the PC that we're connecting to. The client is accessing those PC's via remote desktop and then starting IE to make the web connection.
All of this works fine. The issue arrises later in the day after we've connected and done what we need to and after the client has disconnected the remote desktop session.
After a while the application looses the ability to communicate with the emulator and the emulator cannot maintain its conection to the host and an application freeze-up insues. As soon as the client uses remote desktop, or logs back in directly at the terminal everything "wakes up" and starts connecting and communicating.
Now, just thinking about it this behavior is expected. After all we're starting and/or running an application under a specific logon. Then after a while the session timeout and locks the workstation. Since this application does not run as a serice, I assume that Windows can't be sure that this program has permission to run anymore and blocks its threads from running until the user that started the program logs back in. We experienced this same issue with some in-house systems and concluded that remote desktop was the problem and could verify it. it only happened after we had remote desktopped in then closed the session and didn't log back in to the PC. Usually after several hours.
We're programmers, so we don't know exactly how all the network stuff works and we can't be technically sure that this is the absolute cause. I guess that ultimately we're wanting to know more about this behavior... is it by design? is it unique to VB6? COM? Is there a way around this? Are we doing something wrong?
Any insite that anyone might have on this would be greatly appreciated. Thanks!