"too many file handles open" on Windows 7

Question

Hello,

We use Source Safe since 12 years now, and while we have new computers running on Windows 7 we have a recurrent problem that occurs when we are working on a large number of files (for example when we get recursively the last version of a directory with more than 1000 files or trying to get history).

The error message that always finish to appear on 7 is "too many file handles open".

I have already tried to increase the virtual memory as suggested somewhere on the internet while I looked after a solution, but nothing better.

What we can notice is that half of the computer we have are still running on XP and we don't have the problem on the same database/files.

Thank for your help !!!

Regards,

Answer 1

Which VSS version do you use, and what is your system configuration? Do you use VSS automation to get the file history, I think your code get the error "ESS_FILE_TOOMANY" from IVSS, and could you please help to check the file handles your process opened via Process Explorer tool.

Sincerely,

---

Bob Bao [MSFT]
MSDN Community Support | Feedback to us

Answer 2

Hello,

The problem occurs in the VSS client (both 6.0 and 2005), we are not using VSS from our own program. I have attached two images from Process Explorer of the ssexp.exe process, one before I do the History command and one when I get the error message ""too many file handles open". It does not seems odd but I hope it can give you usefull information.

Thank you,

Before to get the History:

When I get the error message :

Answer 3

Hi,

Could you please check the Handles view from Process Explorer:

I will help to consult it internally, thanks.

Sincerely,

---

Bob Bao [MSFT]
MSDN Community Support | Feedback to us

Answer 4

Hello Bob,

Please find below the info you ask, I hope this is what you are looking for.

Thank you very much for your help!

Jean-Georges.

Process: ssexp.exe Pid: 5400

Type Name
ALPC Port \RPC Control\OLE1526238B5CDA4291A2FCFAF47308
Desktop \Default
Directory \KnownDlls
Directory \KnownDlls32
Directory \KnownDlls32
Directory \Sessions\1\BaseNamedObjects
File C:\Windows
File C:\Windows\SysWOW64
File C:\Windows\winsxs\x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4053_none_cbf21254470d8752
File C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a
File C:\Windows\winsxs\x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.4053_none_cbf21254470d8752
File C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a
File C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc
File C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a
File C:\Windows\winsxs\x86_microsoft.vc80.mfcloc_1fc8b3b9a1e18e3b_8.0.50727.4053_none_03ca5532205cb096
File \Device\KsecDD
File C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc
File C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc
File C:\Windows\Fonts\StaticCache.dat
File \Device\Mup\VSSLINUX\big_safe\CactusProject\data\loggedin\Jgl.log
File C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a
File C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc
File \Device\Mup\VSSLINUX\big_safe\CactusProject\data\m\mdebaaaa
File \Device\Mup\VSSLINUX\big_safe\CactusProject\data\m\mdebaaaa.b
File \Device\Mup\VSSLINUX\big_safe\CactusProject\data\rights.dat
File C:\Users\Jgl\AppData\Local\Temp\1330941467.srcsafe
File \Device\Mup\VSSLINUX\big_safe\CactusProject\data\names.dat
File \Device\Mup\VSSLINUX\big_safe\CactusProject\data\status.dat
Key HKLM\SYSTEM\ControlSet001\Control\Nls\CustomLocale
Key HKLM\SYSTEM\ControlSet001\Control\Nls\Sorting\Versions
Key HKLM\SYSTEM\ControlSet001\Control\SESSION MANAGER
Key HKLM
Key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\DllNXOptions
Key HKLM\SYSTEM\ControlSet001\Control\NetworkProvider\HwOrder
Key HKCU
Key HKLM\SYSTEM\ControlSet001\Control\Nls\Locale
Key HKLM\SYSTEM\ControlSet001\Control\Nls\Locale\Alternate Sorts
Key HKLM\SYSTEM\ControlSet001\Control\Nls\Language Groups
Key HKCU\Software\Microsoft\SourceSafe\Databases
Key HKCU\Software\Classes
Key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer
Mutant \Sessions\1\BaseNamedObjects\DBWinMutex
Mutant \Sessions\1\BaseNamedObjects\MSCTF.Asm.MutexDefault1
Section \Sessions\1\BaseNamedObjects\MSSCCIShareData5400
Section \Sessions\1\BaseNamedObjects\windows_shell_global_counters
Thread ssexp.exe(5400): 2832
Thread ssexp.exe(5400): 6248
Thread ssexp.exe(5400): 6248
Thread ssexp.exe(5400): 8292
WindowStation \Sessions\1\Windows\WindowStations\WinSta0
WindowStation \Sessions\1\Windows\WindowStations\WinSta0

Answer 5

You are correct.  Seemingly, Windows 7 does allocate file handles based on memory and page size.

I have some questions for you.

What build number of Visual SourceSafe 2005 do you have?  Go to Help > About Microsoft Visual SourceSafe and send me the build number.

Does this occur if you disable antivirus or prevent the AV from scanning your VSS data and your local folder?

If you run the  VSS 2005 under Windows XP Service Pack 3?  Right click the Visual SourceSafe 2005 shortcut and choose Properties.  In the  Compatibility tab, check the "Run this program in compatibility mode for:" and choose Windows SP SP3.

Can you post the contents of your Srcsafe.ini file?

 

---

Trevor Hancock (Microsoft)
Please remember to "Mark As Answer" the replies that help.

Answer 6

Hello Trevor,

The problem occurs with both version of VSS client we use (6.0B build 9119 --- 2005 V8.0.50727.1551).

Regarding the AV, I have tried to disable it and the problem occurs again.

I have also already tried before the compatibility mode hint.

Nothing works...

Thank you,

ADD : Please find below the scrsafe.ini as requested, I hope it can help... Thank you again !

; srcsafe.ini
;
; Three of these variables -- Data_Path, Users_Path, and Users_Txt -- must
; be in srcsafe.ini.  Any other variable here can be overridden in ss.ini.
; Similarly, any ss.ini variable can be placed in srcsafe.ini to set a
; system "default," which individual users can still override in ss.ini.

; The two important paths used by SourceSafe.
Data_Path = data
Temp_Path = temp

; This tells admin where to put personal directories for new users.
Users_Path = users

; From this, find users.txt; from that, in turn, find ss.ini for a user.
Users_Txt = users.txt

; The following line contains common file groupings.
File_Types = VB (*.asp;*.bas;*.cls;*.ct?;*.dca;*.dep;*.dob;*.dox;*.ds?;*.fr?;*.log;*.oca;*.pag;*.pgx;*.res;*.swt;*.vb?), VC (*.bmp;*.c;*.cpp;*.cur;*.cxx;*.def;*.ds?;*.h;*.hpj;*.hpp;*.hxx;*.ico;*.inl;*.mak;*.rc;*.rc2;*.rgs), VID (*.asa;*.asp;*.css;*.dbp;*.dtq;*.htm*;*.pkp;*.sln;*.sql;*.txt;*.vip;*.wdm), VJ (*.java;*.vjp;*.pkp;*.sln;*.txt), VFP (*.cdx;*.db?;*.dc?;*.fpt;*.fr?;*.idx;*.lb?;*.mn?;*.mpr;*.pj?;*.prg;*.qpr;*.sc?;*.vc?)
Multiple_Checkouts = Yes
Shadow =
Keyword_Masks = *.cpp, *.c, *.h
Checkout_LocalVer_Disabled = No
Use_Network_Name = No

Answer 7

Hi Jean-Georges,

I tested this scenario with Windows 7 and Visual SourceSafe 2005 (build 1551). I placed 5004 files in a folder structure in VSS.  I did a Get Latest on my Windows 7 machine, and I do not get the error.  I then used your Srcsafe.ini file, and I still do not get an error. Another colleague has tried as well without success. I am sorry, but we cannot reproduce this.

From a support perspective this is really beyond what we can continue with here in the forums. If you cannot determine your answer here or on your own, please consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:  http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone.

---

Trevor Hancock (Microsoft)
Please remember to "Mark As Answer" the replies that help.

Answer 8

Hello Trevor,

First thank you very much to spent time on trying to help us! We really appreciate!

The fact you cannot reproduce the bug give me an idea of what should be really different in our situation: our server. In fact we do not use a windows computer as server but a linux one. So I have tried to copy the database on a windows machine, connect from 7 and it works! Unfortunately we have choosen a linux machine for good reasons and I cannot change it.

So, the problem must be between VSS/Windows 7 and linux. May be that knowing this you can give us some advice or solution ?

Thank you,

Answer 9

Jean-Georges,

As a side note, this is not really a VSS issue as VSS is working as designed.  We've encountered this with SourceOffSite as well -http://support.sourcegear.com/viewtopic.php?f=10&t=14204

I see two options you face:

a)  Try to tune your Linux install.  I don't know if this will work for certain, but you could try increasing the hard/soft limits of open file descriptors in /etc/security/limits.conf, and you may also need to increase the maximum allowable file handles in /proc/sys/fs/file-max as well.  Searching for "increase file descriptors" or "samba too many open handles" should give you more info on configuring these files.

b)  If that doesn't work, you may need to move the VSS database to a Windows machine.

Let us know if either solution works.

---

Jeff Clausius - SourceGear

Stretching VSS to its limits? Have you looked at SourceGear Vault?

Answer 10

Hello,

I finnaly find a good time to shutdown the server and try some change on the linux server. Unfortunately it does not work...

After several other tests it is definitively something wrong between all our Windows 7 and our Linux server and VSS client as it works perfectly when the same databases are moved on a windows machine (I also tried with new database with the same result).

Anyway, thank you very much for your help and your time on this!!!

Regards,