Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Resource error - maybe.
I have a crash happening with terminal services users when they do a certain menu function.
It is not happening with users that are diest to the server.
Here is the response from their it people.
Is there any srp function that maybe I am not doing some sort of release
- is srp_stopwatch a known problem in some cases.
Working through client and server (Wollongong office) via working terminal server is two different thing totally.
In terminal server environment the cpu, ram, hardrive and os resources is shared/split. It makes it as the users to think they are using their own computer but in reality they are not.
Microsoft applications know about terminal server environment so they are design to take advantage of terminal server environment and understand what it needs for each user session to happen when they log in and log off.
However, some programs like funeral manager must not release the information when session ends for each user.
Hence, when we reboot the terminal server all the cache or info or whatever you want to call it gets deleted or release and once again you are able to work.
We have no idea how funeral manager operates or keep these info within windows os.
So in short we have no idea how to fix this permanently and we need to pass this to your program developer which is Barry.
The other option we have for you to schedule a reboot of your terminal server every night say at 10pm. So in the mornings you don’t have this issue.
It is not happening with users that are diest to the server.
Here is the response from their it people.
Is there any srp function that maybe I am not doing some sort of release
- is srp_stopwatch a known problem in some cases.
Working through client and server (Wollongong office) via working terminal server is two different thing totally.
In terminal server environment the cpu, ram, hardrive and os resources is shared/split. It makes it as the users to think they are using their own computer but in reality they are not.
Microsoft applications know about terminal server environment so they are design to take advantage of terminal server environment and understand what it needs for each user session to happen when they log in and log off.
However, some programs like funeral manager must not release the information when session ends for each user.
Hence, when we reboot the terminal server all the cache or info or whatever you want to call it gets deleted or release and once again you are able to work.
We have no idea how funeral manager operates or keep these info within windows os.
So in short we have no idea how to fix this permanently and we need to pass this to your program developer which is Barry.
The other option we have for you to schedule a reboot of your terminal server every night say at 10pm. So in the mornings you don’t have this issue.
Comments
The SRP_Stopwatch is about as non-SRP tech as it gets. It is nothing but standard BASIC+ that uses named commons. It is highly unlikely that it is the source of your problems. There are utilities that will consume resources and the docs will tell you to release the resources lest you experience something akin to a memory leak. However, it is not possible to list out for you every possible utility that might be the problem here.
Is the terminal server also running the Linear Hash service - NO
in the sequence you see them in the event viewer this is the order.
**1**
Windows cannot access the file for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program OpenInsight because of this error.
Program: OpenInsight
File:
The error value is listed in the Additional Data section.
User Action
1. Open the file again. This situation might be a temporary problem that corrects itself when the program runs again.
2. If the file still cannot be accessed and
- It is on the network, your network administrator should verify that there is not a problem with the network and that the server can be contacted.
- It is on a removable disk, for example, a floppy disk or CD-ROM, verify that the disk is fully inserted into the computer.
3. Check and repair the file system by running CHKDSK. To run CHKDSK, click Start, click Run, type CMD, and then click OK. At the command prompt, type CHKDSK /F, and then press ENTER.
4. If the problem persists, restore the file from a backup copy.
5. Determine whether other files on the same disk can be opened. If not, the disk might be damaged. If it is a hard disk, contact your administrator or computer hardware vendor for further assistance.
Additional Data
Error value: C00000C4
Disk type: 0
**2**
Faulting application name: OINSIGHT.exe, version: 9.4.0.0, time stamp: 0x51ad1331
Faulting module name: SRPControls.OCX, version: 4.0.2.0, time stamp: 0x57c65439
Exception code: 0xc0000006
Fault offset: 0x007b8640
Faulting process id: 0x1aa0
Faulting application start time: 0x01d30bfa66a40914
Faulting application path: \\Dc\oi7parsons\OINSIGHT.exe
Faulting module path: \\Dc\oi7parsons\SRPControls.OCX
Report Id: 63bd71ab-77ef-11e7-8112-000c292d3ba0
Faulting package full name:
Faulting package-relative application ID:
After pushing I found that the problem occurs when they are in a certain screen.
I saw this in the code
Set_Property(@Window:".OLE_TAB", "OLE.FlickerFree", 1)
But it is not getting set to 0 on a close event and this screen would be getting opened numerous times.
Would that be a concern to you. (I will fix of course)
OI Crashing for remote users
OI Crashing on Terminal Server
SRP_COM vs OI com programming
The problem with all of these issues is the inability to reproduce on demand. Not setting the FlickerFree property to 0 is a known issue, but it is hard to tell whether this is your problem or if it will help to set it to 0.
Now one told me. 'It had writing all over the screen and I am sure it was swearing and said bugger..'
Grrr, they have rebooted and cant now get the crash we will have to wait and see if happens again.
btw, was the other reported crashes getting the debugger.