C / C++ / MFC

4-Apr-13 23:31

I have weird bug: in a MDI aplication, if I mapped OnFileOpen in follow way:

C++

ON_COMMAND(ID_FILE_OPEN, OnFileOpen)

after the document file has opened, the application crashes with follow message:

C++

(KERNELBASE.DLL): 0xC0000005: Access Violation.

but only in Release mode ... in Debug mode, everything is going well ...
if I mapped OnFileOpen in follow way:

C++

ON_COMMAND(ID_FILE_OPEN, CWinApp::OnFileOpen)

again, everything is going well ... did you meet with this behaviour ? Perhaps you give some hint ... Thank you.

CPallini4-Apr-13 23:40

CPallini

4-Apr-13 23:40

In a Debug build the compiler performs additional tasks, for instance it zeroes variables you haven't initialized (e.g. WinAPI structs) (in Release build the unitialized data contains garbage).
Have a look at the following CodeProject article: "Surviving the Release Version"[^].

Veni, vidi, vici.

Jochen Arndt4-Apr-13 23:42

4-Apr-13 23:42

Check your CMyApp::OnFileOpen() code and the functions that are called from there. Comment all lines in that function except the base class CWinApp::OnFileOpen() call and uncomment step by step until the violation occurs. Then you should know which part of your code is responsible.

_Flaviu5-Apr-13 0:07

5-Apr-13 0:07

Inside of CMyApp::OnFileOpen I didn't call CWinApp:OnFileOpen .. here is the buggy code:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlgFile(TRUE);
	dlgFile.DoModal();
	return;
}

and in release mode, the application crashes ...

_Flaviu5-Apr-13 0:26

5-Apr-13 0:26

Even if I used:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlgFile(TRUE);
	return;
}

and the application is crashing down ...

Jochen Arndt5-Apr-13 0:35

5-Apr-13 0:35

Crashes it in this function or later?

If you did not call CWinApp::OnFileOpen(), no document is created. So the reason for the crash is probably somewhere in your document creation. Did you call OnFileNew() or use ProcessShellCommands() to create a document?

_Flaviu5-Apr-13 0:46

5-Apr-13 0:46

No, I didn't call CWinApp::OnFileOpen, but I call OpenDocumentFile(...), something like that:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlg(TRUE);
	if(IDOK == dlg.DoModal())
	{
		POSITION pos = dlg.GetStartPosition();
		while(pos)OpenDocumentFile(dlg.GetNextPathName(pos));
	}
	// the document is loaded, I can see the bitmap in child frame ...
	AfxMessageBox("By here, everything it's OK.");
}

after all, I think that the problem it's in another place ... I really don't know ...

And this is weird, because if I open the same file from MRU, everything is OK ...

modified 5-Apr-13 5:54am.

Jochen Arndt5-Apr-13 1:12

5-Apr-13 1:12

It's difficult to find such errors in release versions. Using a message box is a good idea to check where the violation occurs. Because it occurs when not calling OpenDocumentFile(), I assumed that it is somewhere in the document handling (e.g. trying to access non-existing documents).

But when it is OK using ProcessShellCommands() (MRU) D'Oh! | :doh:

At the moment I have only two ideas:

Call OpenDocumentFile() with a fixed file name to see what happens (no other calls from within OnFileOpen()).
Perform a complete rebuild if you have changed something in your project.

_Flaviu5-Apr-13 1:27

5-Apr-13 1:27

This is became strange: if I call only:

C++

OpenDocumentFile(_T("D:\\Flaviu\\SampleImages5\\Test.xxx"));

, everything is OK, but when I go through normal way:

C++

CString strFile;
if (dlgFile.DoModal()==IDOK)
{
    pos=dlgFile.GetStartPosition();
    while (pos!=NULL)
    {
        strFile=dlgFile.GetNextPathName(pos);
        AfxMessageBox(strFile);
        OpenDocumentFile(strFile);
    }
}

is crashing down ... in Release mode only ...
I have to digg in ...

Jochen Arndt5-Apr-13 1:31

5-Apr-13 1:31

So the problematic code is at least isolated even when it looks OK. As next step you may assign the fixed file name to strFile ignoring the selection from the dialog.

_Flaviu5-Apr-13 1:32

5-Apr-13 1:32

Another trial:

C++

CString strFile;
if (dlgFile.DoModal()==IDOK)
{
    pos=dlgFile.GetStartPosition();
    while (pos!=NULL)
    {
        strFile=dlgFile.GetNextPathName(pos);
        AfxMessageBox(strFile);
        OpenDocumentFile(strFile);
    }
}

AfxMessageBox("Second chance");
OpenDocumentFile(_T("D:\\Flaviu\\SampleImages5\\Test.xxx"));
AfxMessageBox("Final ...");

the crashes is occur only after the "final" message box ...

SoMad5-Apr-13 1:51

SoMad

5-Apr-13 1:51

Did you try doing a Rebuild All like Jochen suggested?

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

_Flaviu5-Apr-13 2:24

5-Apr-13 2:24

Of course I did ... something weird is happend ... because if I use only CFileDialog dlgFile(TRUE); in CMyApp::OnFileOpen and the application is crashing down .. I wonder if CFileDialog doesn't have some bug ... Confused | :confused:

SoMad5-Apr-13 11:58

SoMad

5-Apr-13 11:58

Sorry, I did not mean to insult you, but when something really weird is going on, Rebuild All is a good thing to do. I wanted to make sure you had tried that because just last week, I had a weird string related problem that I was trying to chase down. Rebuild All was not my first thought, so I ended up spending at least an hour trying to make sense of it before I finally did the rebuild, which fixed the problem.

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

_Flaviu5-Apr-13 3:18

5-Apr-13 3:18

I found the problem: the destructor of CFileDialog has problems, and I had solved in follow way: I used CFileDialog variable on the heap, just like this:

C++

CFileDialog* pDlgFile = new CFileDialog(TRUE);
// do whatever with pDlgFile ...
delete pDlgFile;

and everything it's OK now ...
I want to kindly thank you all of you for your interest and patience ! Best wishes for you ! Bye.

modified 5-Apr-13 9:12am.

David Crow5-Apr-13 4:14

David Crow

5-Apr-13 4:14

Flaviu2 wrote:
I found the problem...

Moving variables from the stack to the heap is usually not the solution to a problem. You likely just masked it.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

Richard MacCutchan5-Apr-13 4:35

Richard MacCutchan

5-Apr-13 4:35

Flaviu2 wrote:
the destructor of CFileDialog has problem

More likely you are referring to a variable that has been destroyed as your dialog has gone out of scope.

Use the best guess

Windows Service Controler & CAsyncSocket

SoMad5-Apr-13 8:39

SoMad

5-Apr-13 8:39

I know you say your modification fixed the crash, but it made me recall a problem that existed in previous versions of Visual Studio: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/55664186-aae7-4ae9-a3e9-e38659335df6[^]

So, I did a few searches and came across this: http://mfctips.com/category/cfiledialog/[^]. I realize it does not appear to be an exact match since yours crashes in Release builds, but one of the comments leads to a Microsoft hotfix, which seemed to solve the problem for several people: http://support.microsoft.com/kb/2718841/en-us[^]

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

Member 33971274-Apr-13 21:43

Member 3397127

4-Apr-13 21:43

i have problem with CAsyncSocket class when i called listen in widows service application.

i successfully create Thread but my listen fuction didn't work correctly.

here my code..

C++

BOOL CMyThread::InitInstance()
{	
	while (!AfxSocketInit());
	MySocket sock;
	while (sock.Create(3005)==SOCKET_ERROR);
	while (sock.Listen()==SOCKET_ERROR);
	HANDLE file;
	file=CreateFile(_T("C:\\initinstance.txt"),GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_NEW,FILE_ATTRIBUTE_NORMAL,NULL);
	CloseHandle(file);
	return TRUE;
}

my application create "initinstance.txt" file successfully but when use commmand "netstat -na" port 3005 not listening..
Frown | :(

where is my mistake?

Re: Windows Service Controler & CAsyncSocket

Jochen Arndt4-Apr-13 23:55