結論來看，是一個簡單又樸素的道理——開啟檔案控制代碼用完了得給關上。
表現在現象上卻是著實讓人費解，以至於有人還懷疑起了微軟的Winodws系統來了，可笑至極。
還是那句話，先把自己的屁股先給擦乾淨嘍再懷疑別人吧！

引申到另一個話題 ，一個較大型程式存在此類檔案控制代碼耗盡的問題，該如何去排查呢？
一個簡單原始的辦法——開啟Procmon（Process Monitor）分析所有的CreateFile與CloseFile個數，就會發現某個或某些檔案的關閉不足夠了。
可能有人會說我用的是fopen，也沒用CreateFile啊。其實啊，只要是Windows系統，fopen這類C的庫函式最終肯定會呼叫CreateFile來的。
且這個fopen的509次限制（至少Windows）應該也是這個C的庫函式中加入的，實踐證明使用CreateFile替換fopen後程序又愉快地工作了。
當然使用CreateFile替換fopen只是一時的迂迴，根本上還是得把控制代碼給及時釋放掉以免造成更大的怪事情。

1，背景：測試部說錄影不成功，經小維查明是fopen返回NULL導致

工程程式碼：
FILE* pFile = fopen(recPath, "wb");
if (NULL == pFile)
{
     printf("fopen return NULL, error=%d/n", GetLastError());
}
失敗時列印：fopen return NULL, error=0
繼續執行時列印：fopen return NULL, error=183

分析（懷疑是fopen後未fclose所致，寫一測試程式碼）：
int i = 0;
for (i = 0; i < 1000; i++)
{
      pFile = fopen(sPath, "wb");//sPath每次都不同
      if (NULL == pFile)
      {
             printf("[%d]fopen return NULL, error=%d/n", i, GetLastError());
       }
}
在winxp下測試，發現前508個檔案都沒問題，509個檔案開始都是返回NULL，並且error=0
關閉程式再執行一次，一樣，前508個檔案都沒問題，但是error=183
error=183的意思是：當檔案已存在時，無法建立該檔案。

改為CreateFile再測，1000個檔案建立成功，沒有出錯

結論：
1、GetLastError()並不能精確實時獲取fopen的錯誤，
2、fopen控制代碼數目有限制
建議：
1、fopen後一定要fclose
2、建議win下用CreateFile代替fopen

聽說linux下fopen控制代碼數目只能支援17個？有興趣的朋友可測試一下
---------------------
作者：pizicai105
來源：CSDN
原文：https://blog.csdn.net/pizicai105/article/details/6128354
版權宣告：本文為博主原創文章，轉載請附上博文連結！

2，http://www.cnblogs.com/personnel/p/4585033.html      by 沙的空間

fopen() 返回 NULL, 奇葩原因:當前程序開啟多個控制代碼，忘記關閉。(bug)
今天在測試一個程式的時候，突然第一次彈出錯誤對話方塊，提示： 建立新檔案失敗。 fopen() 返回 NULL

我又重啟程式測試，還是提示同樣的錯誤。

經過幾分鐘的檢查，發現一個規律：當處理到500多個檔案時，開始掛掉。

終於發現原因，因為有一段程式碼在處理檔案遇到錯誤時，忘記fclose()了。

當處理500多個檔案出錯時，也就意味著當前程序fopen()500多個檔案，剛好windows對程序開啟檔案的控制代碼數有限制(百度一下)。

所以導致：fopen()返回 NULL.