Ingo Foerster
asked on
CStdioFile Access Violation
Hello,
I use in my software CStdioFile. It has worked now for many years but now I get messages that the software will cause Access Violation messaged on growing systems with Windows 7 and Windows 8. I have change the function from CStdioFile to CFile for testing and the access violation do not happen again. But CFile is not good for text.
CStdioFile method:
The CFile method:
Anybody here who know (or have an idea) why this access violation happen and why not with the CFile? Anybody know how to write with the CFile method text to a textfile?
I use in my software CStdioFile. It has worked now for many years but now I get messages that the software will cause Access Violation messaged on growing systems with Windows 7 and Windows 8. I have change the function from CStdioFile to CFile for testing and the access violation do not happen again. But CFile is not good for text.
CStdioFile method:
void CPixbyteHelpers::WriteLogFile(CString nLine){
CString logFile = theApp.appHelpers.GetSpecialFolderPath(2);
UINT tFlags;
if(theApp.appHelpers.PixFileExists(logFile)){
tFlags = CFile::modeWrite | CFile::shareDenyNone;
}else{
tFlags = CFile::modeCreate | CFile::modeWrite | CFile::shareDenyNone;
}
CStdioFile f(logFile, tFlags);
f.SeekToEnd();
f.WriteString(nLine);
f.WriteString(_T("\n"));
f.Close();
}
The CFile method:
void CPixbyteHelpers::WriteLogFile(CString nLine){
CString logFile = theApp.appHelpers.GetSpecialFolderPath(2);
HANDLE hFile = CreateFile(logFile,
GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
AfxMessageBox(_T("Couldn't create the file!"));
}
else
{
// Attach a CFile object to the handle we have.
CFile myFile(hFile);
myFile.SeekToEnd();
static const TCHAR sz[] = _T("\n");
// write string
myFile.Write(nLine.GetBuffer(nLine.GetLength()), nLine.GetLength());
nLine.ReleaseBuffer();
myFile.Write(sz, sizeof(sz));
// We can call Close() explicitly, but the destructor would have
// also closed the file for us. Note that there's no need to
// call the CloseHandle() on the handle returned by the API because
// MFC will close it for us.
myFile.Close();
Sleep(100);
}
}
Anybody here who know (or have an idea) why this access violation happen and why not with the CFile? Anybody know how to write with the CFile method text to a textfile?
ASKER
The path is "C:\Progamdata\CinExHD\Log \Rangerlog .log"
But as I wrote, with CStdioFile it get on some computer an access violation and with CFIle not.
This is what confuse to me.
But as I wrote, with CStdioFile it get on some computer an access violation and with CFIle not.
This is what confuse to me.
Can you reproduce the issue? If yes, which line exactly in the above causes teh exception?
ASKER
I can only check this issue with Teamviewer on the customer computer and so I do not have an exact line.
I can reproduce the error on this computer in different parts of the software and I get more and more reports of other computers. It was no problem before.
I can reproduce the error on this computer in different parts of the software and I get more and more reports of other computers. It was no problem before.
It seems to be an access right issue as already told by JKR. Please check that.
In general, don't try to create log file in program files or some other path except document setting/ user. User path always allows you to write by default. So u never fall in this issue.
In general, don't try to create log file in program files or some other path except document setting/ user. User path always allows you to write by default. So u never fall in this issue.
ASKER
Sorry it is definitly not an access right problem. The access rights are set by the installer perfect. The security settings show the same as on other computers. I also can grant full access with admin account. Same error. I can also run as administrator, same problem.
In review MS documents, ProgramData (CSIDL_COMMON_APPDATA) folder is the perfect place to store information.
However, why CStdioFile throws a access violation and CFile do not. Same computer, same file, same location.
In review MS documents, ProgramData (CSIDL_COMMON_APPDATA) folder is the perfect place to store information.
However, why CStdioFile throws a access violation and CFile do not. Same computer, same file, same location.
R u using any logger?So we can see the code flow where it's happening.Else Try to reproduce and debug.
ASKER
I use now the Flags following way:
if(theApp.appHelpers.PixFileExists(logFile)){
tFlags = CFile::modeReadWrite | CFile::shareExclusive | CFile::typeText | CFile::osWriteThrough;
}else{
tFlags = CFile::modeReadWrite | CFile::modeCreate | CFile::shareExclusive | CFile::typeText | CFile::osWriteThrough;
}
This works now.
Hi Ingo Foerster,
it would be really helpful to know the exact place in MFC where the access violation occurs. It could be possible to find out where it happens creating a dump in case the access violation happens. To do this a customer who reproducable encounters the problem can configure automatic generation of a dump in registry as described at http://msdn.microsoft.com/en-us/library/bb787181%28v=vs.85%29.aspx.
After this the customer can send you the create dump (a .dmp file), then you should be able to open it in VisualStudio and start a debug session as described at http://msdn.microsoft.com/en-us/library/d5zhxt22%28v=vs.110%29.aspx
Thus it should be possible to see where the access violation is caused - if so please post the call stack here and maybe screenshot showing the relevant parts of your and MFC's code.
BTW: What VisualStudio version do you use?
Best regards,
ZOPPO
it would be really helpful to know the exact place in MFC where the access violation occurs. It could be possible to find out where it happens creating a dump in case the access violation happens. To do this a customer who reproducable encounters the problem can configure automatic generation of a dump in registry as described at http://msdn.microsoft.com/en-us/library/bb787181%28v=vs.85%29.aspx.
After this the customer can send you the create dump (a .dmp file), then you should be able to open it in VisualStudio and start a debug session as described at http://msdn.microsoft.com/en-us/library/d5zhxt22%28v=vs.110%29.aspx
Thus it should be possible to see where the access violation is caused - if so please post the call stack here and maybe screenshot showing the relevant parts of your and MFC's code.
BTW: What VisualStudio version do you use?
Best regards,
ZOPPO
ASKER
Hi Zoppo,
waht you have written is a good workflow but sorry, the people do not work this way. Most people do not send the dump because they think inside are personal information. Some people do not send it because they do not want.
Also many people report an problem "The software do no work". A follow up mail will not happen. It was luck that this user allowed us to check this issue on his computer with Teamviewer. So yes, there are many ways to get information but the reality is different.
Me myself I have really pain with this issue. Why CStdioFile fials on some windows systems and on the same System it works with CFile. And now with changing the flags it works too.
With the experience I have with Antivirus software I think that Bitdefender cause this problem. I think it checks all files that will be open and closed. Our software will write really much information to the log file on startup and in case of different classes and objects everytime an file open and file close happen. If now an hooking software like Bitdefender checks every time the file, the access violation happen. Maybe with the option to write directly there is no buffer and queue and so it works now. It makes the software slower but I can life with it.
So tank you for your help.
waht you have written is a good workflow but sorry, the people do not work this way. Most people do not send the dump because they think inside are personal information. Some people do not send it because they do not want.
Also many people report an problem "The software do no work". A follow up mail will not happen. It was luck that this user allowed us to check this issue on his computer with Teamviewer. So yes, there are many ways to get information but the reality is different.
Me myself I have really pain with this issue. Why CStdioFile fials on some windows systems and on the same System it works with CFile. And now with changing the flags it works too.
With the experience I have with Antivirus software I think that Bitdefender cause this problem. I think it checks all files that will be open and closed. Our software will write really much information to the log file on startup and in case of different classes and objects everytime an file open and file close happen. If now an hooking software like Bitdefender checks every time the file, the access violation happen. Maybe with the option to write directly there is no buffer and queue and so it works now. It makes the software slower but I can life with it.
So tank you for your help.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Open in new window