Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 275
  • Last Modified:

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:
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();
}

Open in new window


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);
	}

}

Open in new window


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?
0
Ingo Foerster
Asked:
Ingo Foerster
  • 5
  • 2
  • 2
  • +1
1 Solution
 
jkrCommented:
What path is "theApp.appHelpers.GetSpecialFolderPath(2);" referring to? It is very likely that you fell victim to Windows' File system virtualization. See the article at http://www.codeproject.com/Articles/17968/Making-Your-Application-UAC-Aware ("Making Your Application UAC Aware") which has a section addressing that. It is probably best summed up with the following snippet (taken from that article):

Real path
C:\Program Files\Foo\Foo bar\config.ini

Virtual path
C:\Users\<account>\AppData\Local\VirtualStore\Program Files\Foo\Foo bar\config.ini 

Open in new window

0
 
Ingo FoersterProgrammerAuthor Commented:
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.
0
 
jkrCommented:
Can you reproduce the issue? If yes, which line exactly in the above causes teh exception?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Ingo FoersterProgrammerAuthor Commented:
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.
0
 
Subrat (C++ windows/Linux)Software EngineerCommented:
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.
0
 
Ingo FoersterProgrammerAuthor Commented:
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.
0
 
Subrat (C++ windows/Linux)Software EngineerCommented:
R u using any logger?So we can see the code flow where it's happening.Else Try to reproduce and debug.
0
 
Ingo FoersterProgrammerAuthor Commented:
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;
	}

Open in new window

This works now.
0
 
ZoppoCommented:
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
0
 
Ingo FoersterProgrammerAuthor Commented:
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.
0
 
ZoppoCommented:
Hm - if your customers aren't willing to help you finding the cause it's of course difficult. Maybe you can ask to create and analyze a dump on their machine using TeamViewer too so they can watch what you're doing? This would mean you'd have to implement a debugger (i.e. WinDbg) there.

Another possibility to find if there's a sharing violation or something you could ask them to install Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), with this you can create a detailed traceout to i.e. report file API function calls.

Beside this I don't see a way to find the real cause as long as you're not able to reproduce it.

Allthough your workaround works IMO it would be nice to find the cause to ensure there won't occur similar problems with other functionalities or applications. I'm not sure if I believe BitDefender causes this because in this case I would expect there's a huge amount of applications which would behave similar.

I'm not sure if the CFile::osWriteThrough fixes it, you even use other different flags compared to the original posted code regards sharing and read/write access.

BTW: Does your program use multi threading? If so, could it be the function is called simultanuously form different threads?

And a hint: You don't need to check the existance of the file when you use CFile::modeNoTruncate, so simply setting the flags to CFile::modeReadWrite | CFile::modeCreate | CFile::modeNoTruncate | CFile::shareExclusive | CFile::typeText | CFile::osWriteThrough; does the same without need to know whether the file exists before.

ZOPPO
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now