The problem is: When the wrun32 application is crashed or closed by the task manager a part of wrun32.exe is still running. (64-bit W2008-R2)
Normally causes a crashed runtimer no problem, because the user starts a new one, but a crashed runtimer in a lock situation will result in a read-lock error (status 99) for all users !!!!!!
In a terminal server environment it is hard to determine which wrun32 causes a lock-situation when the user did not report a crash. In this case the customer has 25 users and at least the same amount of wrun32 processes.
The Help-desk could not help me with this MICROSOFT problem,
Who can help me with a solution for this problem ?
Are you using a mapped drive as the way that all users read / write / update the data files? If so, consider using AcuServer.
The problem is: When the wrun32 application is crashed or closed by the task manager a part of wrun32.exe is still running. (64-bit W2008-R2)
Normally causes a crashed runtimer no problem, because the user starts a new one, but a crashed runtimer in a lock situation will result in a read-lock error (status 99) for all users !!!!!!
In a terminal server environment it is hard to determine which wrun32 causes a lock-situation when the user did not report a crash. In this case the customer has 25 users and at least the same amount of wrun32 processes.
The Help-desk could not help me with this MICROSOFT problem,
Who can help me with a solution for this problem ?
Yes, we do.
In my opinion AcuServer handles only the data, but what does AcuServer with the remaining part of WRUN32 responsible for locking that data ??
Even on my single user notebook (64 bit W7 Pro) gives the same problem!
The problem is: When the wrun32 application is crashed or closed by the task manager a part of wrun32.exe is still running. (64-bit W2008-R2)
Normally causes a crashed runtimer no problem, because the user starts a new one, but a crashed runtimer in a lock situation will result in a read-lock error (status 99) for all users !!!!!!
In a terminal server environment it is hard to determine which wrun32 causes a lock-situation when the user did not report a crash. In this case the customer has 25 users and at least the same amount of wrun32 processes.
The Help-desk could not help me with this MICROSOFT problem,
Who can help me with a solution for this problem ?
Yes, we do.
In my opinion AcuServer handles only the data, but what does AcuServer with the remaining part of WRUN32 responsible for locking that data ??
Even on my single user notebook (64 bit W7 Pro) gives the same problem!
The problem is: When the wrun32 application is crashed or closed by the task manager a part of wrun32.exe is still running. (64-bit W2008-R2)
Normally causes a crashed runtimer no problem, because the user starts a new one, but a crashed runtimer in a lock situation will result in a read-lock error (status 99) for all users !!!!!!
In a terminal server environment it is hard to determine which wrun32 causes a lock-situation when the user did not report a crash. In this case the customer has 25 users and at least the same amount of wrun32 processes.
The Help-desk could not help me with this MICROSOFT problem,
Who can help me with a solution for this problem ?
AcuServer does the all of the data I/O including locking. ... There are a lot of articles in the knowledge base that deal with having data on a shared drive ....
community.microfocus.com/.../17516.opportunistic-locking.aspx
microfocus.telligenthosting.net/.../1211.aspx
Also, are you using this configuration variable ... NT_OPP_LOCK_STATUS
This configuration variable controls how files on a shared drive are opened if you are working in the Windows opportunistic locking mode. NT_OPP_LOCK_STATUS can take one of four values: CREATEFILE, SAFE, GETFILETYPE, or FAST. The default value is "SAFE", which is a synonym for "CREATEFILE".
If you set this variable to "GETFILETYPE" or "FAST" (synonyms for each other), the runtime uses the fast method of opening files.
Foe shared drive access it should be set to FAST.
The problem is: When the wrun32 application is crashed or closed by the task manager a part of wrun32.exe is still running. (64-bit W2008-R2)
Normally causes a crashed runtimer no problem, because the user starts a new one, but a crashed runtimer in a lock situation will result in a read-lock error (status 99) for all users !!!!!!
In a terminal server environment it is hard to determine which wrun32 causes a lock-situation when the user did not report a crash. In this case the customer has 25 users and at least the same amount of wrun32 processes.
The Help-desk could not help me with this MICROSOFT problem,
Who can help me with a solution for this problem ?
If I'm not working in Windows opportunistic locking mode, does this variable any effect in the speed process?
