Spinweb922
asked on
Error 108 File is in use by another user
I have a Dell 6850 Server running Windows 2003 server SP2. About a week ago the server went down unexpectedly. There was at least one user on it using Terminal services running a mission critical clinical database program. The Program is developed by a independed software vendor written in VFoxPro. Since the "crash" of the server, users have complained about slowness and frequent error 108 and getting kicked from the server.
I've visited with Dell and we have ran a series of tests on the server's hardward. Nothing found wrong so far. The software vendor is pointing at the server as the issue and Dell is saying software. I did find a slight issue on the C Drive (system) which was corrected via chkdsk. Here are the specs on the server:
4 quad core Xeon CPS
16 GIGS memory
Raid 5 4X320 SAS Drives
2 partitions C: system D: Data (database)
Average user load via RDP is 40 users
Average mem usage per user is 200 megs
Performance monitor show disk activity on D: increases when the 8 Gig mark is hit. System really starts to drag at this pont. PageFile has been resized and even moved (to C) without any inprovement. Any ideas on what could be wrong?
I've visited with Dell and we have ran a series of tests on the server's hardward. Nothing found wrong so far. The software vendor is pointing at the server as the issue and Dell is saying software. I did find a slight issue on the C Drive (system) which was corrected via chkdsk. Here are the specs on the server:
4 quad core Xeon CPS
16 GIGS memory
Raid 5 4X320 SAS Drives
2 partitions C: system D: Data (database)
Average user load via RDP is 40 users
Average mem usage per user is 200 megs
Performance monitor show disk activity on D: increases when the 8 Gig mark is hit. System really starts to drag at this pont. PageFile has been resized and even moved (to C) without any inprovement. Any ideas on what could be wrong?
Reindex?
ASKER
Several reindexing have occured.
You don't have a backup that you can use?
ASKER
Of course we have a backup, however because the system was/is somewhat stable after the incident, users continued to enter data. Now that it's been a week, and the end of a month, it would be impossible to revert to a backup. We do run a test build also to help locate issues, a pre-event backup was pulled and place there. But it also appears sluggish after the 8 gig point is hit. However we have not seen the error 108, although not to many users are accessing it. Just mostly staff that are trying to troubleshoot the issue.
I can completely relate to your woes. I am running a dataflex accounting system here.... :O
Perhaps this link helps?
http://msdn.microsoft.com/en-us/library/aa975932(VS.71).aspx
Have you reviewed your security permissions? Perhaps something changed when you reestablished something? I am shooting in the dark. I hope a VFox Pro comes to your rescue.
Maybe it's time to convince the "powers that be" that it's time to upgrade?
Perhaps this link helps?
http://msdn.microsoft.com/en-us/library/aa975932(VS.71).aspx
Have you reviewed your security permissions? Perhaps something changed when you reestablished something? I am shooting in the dark. I hope a VFox Pro comes to your rescue.
Maybe it's time to convince the "powers that be" that it's time to upgrade?
This error is coded into the application and is not generated by VFP itself. It could be translating a VFP file in use error, or any number of similar issues the software knows about.
WhoHasNT - A tool to determine who is using a file/directory:
http://www.gadgetfactory.com/whohasnt.shtml
File Unlocker:
http://ccollomb.free.fr/unlocker/
Hope this helps
WhoHasNT - A tool to determine who is using a file/directory:
http://www.gadgetfactory.com/whohasnt.shtml
File Unlocker:
http://ccollomb.free.fr/unlocker/
Hope this helps
Actually that is a VFP error number, I just didn't recognize it. Regardless...
Regardless....?
Is it windows causing the problem or is it VFP causing the problem?
Is it windows causing the problem or is it VFP causing the problem?
Hard to say, I can only recommend the tools I mentioned above. They will help identify the file and free it from the clutches of evil. hopefully :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I know creepy magic, if those tools don't work.
Perhaps there are some .tmp files that are clogging the pipes?
Perhaps there are some .tmp files that are clogging the pipes?
Off point however the author only mentioned the software is VFP. But it is possible to still be using a SQL backend, right?
I hope each terminal service should have its own temp folder possibly not on the RAID drive then it should not cause error 108. This error means some problem in shared resources.
If there is SQL then some measurements on the SQL would be useful, as well. But I don't think so because error 108 is not obvious in client server environment.
If there is SQL then some measurements on the SQL would be useful, as well. But I don't think so because error 108 is not obvious in client server environment.
ASKER
pcelba:
"Error 108 can raise due to the fact the application is waiting for resources much longer than ever before and some timeouts are simply too short"
I think you might have something here as the error occurs when the system is sluggish. So this maybe more of a server OS issue than a VFP issue? And BTW you're preaching to the choir on the mission critical app using VFP, I'd much rather it be SQL.
I just completed a sfc /scannow, nothing found there.
I appreciate all the comments, keep them coming.
"Error 108 can raise due to the fact the application is waiting for resources much longer than ever before and some timeouts are simply too short"
I think you might have something here as the error occurs when the system is sluggish. So this maybe more of a server OS issue than a VFP issue? And BTW you're preaching to the choir on the mission critical app using VFP, I'd much rather it be SQL.
I just completed a sfc /scannow, nothing found there.
I appreciate all the comments, keep them coming.
Is there antivirus installed on the server? You may consider exempting the vfp software folder.
Perhaps you should get some sort of deleted data recovery tool. Like this:
http://www.recovermyfiles.com/
It's a tad bit "hokey", but it worked for me once. I had to kill a medicine man to get it, though.
http://www.recovermyfiles.com/
It's a tad bit "hokey", but it worked for me once. I had to kill a medicine man to get it, though.
ASKER
JF0:
The data files are excluded, but we finally shut down the whole service to see if it was affecting performance.
MrMintanet:
I've used recovermyfiles before, if you like a lot of generic names on recoved file it ok. But in this case we didn't really lose anything, we just have a slower server.
The data files are excluded, but we finally shut down the whole service to see if it was affecting performance.
MrMintanet:
I've used recovermyfiles before, if you like a lot of generic names on recoved file it ok. But in this case we didn't really lose anything, we just have a slower server.
Perhaps you should upgrade the PSU?
If it is not problem of large FoxPro data then yes, I think this is more server or OS issue than VFP issue. Errors start rising after the crash. There is something wrong which consumes server resources more than before, so it is slower. It could be some hardware problem which is solved by OS adaptability but it consumes more time than before, it can be some OS patch or update (did you check installed OS updates?).
VFP has its own memory space on terminal service and 200 megs should be enough. Do you have some data size statistics to avoid large VFP data as the possible reason? VFP is able to use disk more heavily if data size exceeds certain limit. Did the application pass some stress testing?
And, sorry for the preaching :-).
VFP has its own memory space on terminal service and 200 megs should be enough. Do you have some data size statistics to avoid large VFP data as the possible reason? VFP is able to use disk more heavily if data size exceeds certain limit. Did the application pass some stress testing?
And, sorry for the preaching :-).
ASKER
pcelba:
Good points. The server did indeed take March updates prior to the crash. However they were removed after we realized there was an issue. I've sent a 6 hour preformance log to Dell hoping they might see something I've missed. I'll keep everyone informed.
Good points. The server did indeed take March updates prior to the crash. However they were removed after we realized there was an issue. I've sent a 6 hour preformance log to Dell hoping they might see something I've missed. I'll keep everyone informed.
I've exhausted my ideas already, hope Dell has some fresh forces. The truth is any VFP application is possible to optimize and brute force is necessary for servers.
When I have encountered "File In Use" errors, I have used a tool which will identify who has that file in-use.
The tool I use is WhoHasNT (http://www.gadgetfactory.com/whohasnt.shtml). It will show the Windows login name for anyone who is currently using a file (of any type).
First I have to have sufficient Error Logging/Trapping in my application to determine which specific file(s) might be the problem. And I need to determine where in the code the problem occurred so that I can more readily duplicate the problem.
Once I know the file(s) I then start with that tool and if someone is found, then I address how/why/when, etc. and work to resolve the conflict. If that tool does not show anyone using the file, then the OS is somehow 'confused' and telling VFP wrong info. That is a much more complicated issue, but it too can be chased down.
Good Luck
The tool I use is WhoHasNT (http://www.gadgetfactory.com/whohasnt.shtml). It will show the Windows login name for anyone who is currently using a file (of any type).
First I have to have sufficient Error Logging/Trapping in my application to determine which specific file(s) might be the problem. And I need to determine where in the code the problem occurred so that I can more readily duplicate the problem.
Once I know the file(s) I then start with that tool and if someone is found, then I address how/why/when, etc. and work to resolve the conflict. If that tool does not show anyone using the file, then the OS is somehow 'confused' and telling VFP wrong info. That is a much more complicated issue, but it too can be chased down.
Good Luck
I've seen situations with terminal server where a previous session cannot be reconnected upon a new login and it creates a new session (I don't recall the error message). Is it possible that the TS session that was cutoff has never been properly terminated? Does the error message and sluggishness problems happen only when the person who was online during the crash reconnects?
ASKER
This issue was resolved by a complete wipe of the server and reinstallation of the operating system. A backup of the Foxpro files were tested (pre-crash) and also exhibited the same errors and freezing. So something must had broke in the OS during the crash. I awarded pcelba the points as he was right in determining the error 108 can be caused by sluggish performance on the server.
ASKER
See the last comment for how we resolved this issue. Thanks!
Thanks for points. But I have to say it is almost impossible to help remotely in similar cases and you did most of the work. Suggestions and ideas from others were useful to me, as well.