TheIronDuke
asked on
Mysterious program crashes counting files in a directory
I have a DLL that is simply using some pretty common code to count files in a directory. On all our test computers, and 98% of people using it, there is no problem. But a few people experience a crash to desktop from this code. I am looking for some possibilities of why this could happen in these isolated cases.
Here is the code:
It is crashing in the do while loop, not at FindFirstFile.
Any ideas?
Here is the code:
int FMSGaugeCallback::getFltPlnsInFolder(wchar_t szPath[MAX_PATH])
{
WIN32_FIND_DATA ffd;
wchar_t szFileName[MAX_PATH];
HANDLE hFind = INVALID_HANDLE_VALUE;
DWORD dwError = 0;
wchar_t szError[255];
wchar_t szDir[MAX_PATH];
int nLen = 0, nDir = 0, nCount = 0;
if (!PathIsDirectory(szPath))
return 0;
PathAddBackslashW(szPath);
swprintf(szDir, sizeof szDir, L"%s*.pln", szPath);
hFind = FindFirstFileW(szDir, &ffd); // Open filefind
if (INVALID_HANDLE_VALUE == hFind) // if process fails record error
{ // and discontinue function
dwError = GetLastError();
swprintf(szError, sizeof szError, ERR_SEARCH_FLT_PLNS, szPath,getLastWinError(dwError));
writeToErrorLog(szError);
return 0;
}
do
{
if (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
{
nDir++; // the flight plan array
}
else
{//-
nCount++;
}//-
} while (FindNextFileW(hFind, &ffd));
FindClose(hFind); // Close filefind
return nCount;
}It is crashing in the do while loop, not at FindFirstFile.
Any ideas?
ASKER
Thanks ZOPPO. I will compile it that way and send it to one of the people experiencing the crash and see if that resolves it.
Don't know if this matters, but it is not FindFirstFile that is causing the crash. It is FindNextFile. The project is already set to UNICODE. The program this is running under is also a UNICODE program.
Don't know if this matters, but it is not FindFirstFile that is causing the crash. It is FindNextFile. The project is already set to UNICODE. The program this is running under is also a UNICODE program.
It is possible that it is hitting a junction folder that causes an infinite loop
ASKER
Shaun,
Since there is no way of knowing what their directory looks like I suppose anything is possible. But how would I detect and protect against that?
Since there is no way of knowing what their directory looks like I suppose anything is possible. But how would I detect and protect against that?
You should be able to exclude junctions
ASKER
Shaun,
How?
How?
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
probably you're mixing UNICODE with none-UNICODE stuff. It is uncommon to use the API functions like FindFirstFileW() directly, usually just FindFirsFile() is used, which versions are used then depends on the UNICODE define.
If you don't use UNICODE I guess FindFirstFileW fails because the struct WIN32_FIND_DATA has two TCHAR members - without UNICODE the TCHAR is a char, but the FindFirstFileW() expects wide chars, so probably data is written beyound the memory of one of these strings.
You should replace the ...W() versions with their generic counter parts and activate UNICODE in the project settings.
Hope that helps,
ZOPPO