Click here to Skip to main content
14,695,329 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have a project that until recently was compiled in Visual Studio 6.0 with no problems. I moved this project to Visual Studio 2008.
It compiles without error in both debug and release mode.

It opens up a MS Access database file and accesses a table.

It works fine in Release Mode, but when I attempt to run the project in Debug mode it throws an exception. The exception occurs after the table is accessed and I attempt to move to the next record.

I have copied some of the output that indicates a possible problem.

Thanks for your help.
'Proj.exe': Loaded 'C:\WINDOWS\system32\odbcint.dll', Binary was not built with debug information.

Warning: ODBC Success With Info, Driver's SQLSetConnectAttr failed
State:IM006,Native : 0,Origin:[Microsoft][ODBC Driver Manager]

DBMS: ACCESS
Version: 04.00.0000
ODBC Driver Manager Version: 03.52.0000
Warning: ODBC Success With Info, String data, right truncated 
State:01004,Native:5,Origin:[Microsoft][ODBC Microsoft Access Driver]

'Proj.exe': Loaded 'C:\WINDOWS\system32\expsrv.dll', Cannot find or open a required DBG file.
Warning: Setting forwardOnly recordset readOnly.
Posted
Updated 30-Mar-11 6:51am
v2

There can be different reasons. By the way, you provide output, not exception. Please, provide full exception dump and show the like of code where it happens. Why forcing us into guesswork?

Anyway, there are typical common problems which cause such situation. Maybe most usual of them is the failure to find some file(s) in one of the configurations, because of incorrect assumptions on the file path. By the way, you can use the Debugger even in Release configuration. The difference is, most likely, not due to running under the debugger, but due to different project configuration, which is not the same. Run under debugger with Release configuration; and you will probably see if the file is still not found.

You should never assume any certain work directory during run-time. The working directory depends on Configuration, but in fact it is defined by the user at the moment of starting the application. You should never use absolute path or assume the path is visible due to Environment variable(s). It means you need to calculate the path to your data file during run-time. This path can be relative to your executable module (but usually only if this is immutable data) or one of the special directories, such as "All users" application data, etc.

[EDIT]
Getting to further detail of the problem needs more exception information; first of all, lines of code where it happens. As your problem is manifested under Debugger, this is not too hard: you can catch exception, put a break point where exception is caught and look for stack using Visual Studio Debug -> Windows -> Call stack. This can be enough to find our there in code it happens for the purpose of reporting it in the CodeProject Question.

Dumping it programmatically is a bit more difficult; I haven't done it in C++ (in .NET its part of standard API), but Google search shows A Simple C++ Function Call Stack Trace Utility[^], http://stackoverflow.com/questions/3355683/c-stack-trace-from-unhandled-exception[^], http://stackoverflow.com/questions/1796225/get-stack-trace-from-uncaught-exception[^].

—SA
   
v2
Comments
23_444 30-Mar-11 13:53pm
   
Here is the message I get from "debug"

There is no source code available for the current location.
23_444 30-Mar-11 14:22pm
   
Unhandled exception at 0x7c92aa5d in Proj.exe: 0xC0000005: Access violation writing location 0x00030ffc.
Sergey Alexandrovich Kryukov 30-Mar-11 17:02pm
   
You see, you don't show full dump; exception stack with code line is especially important. And then look at the reported lines of code. You did not provide any info.
--SA
23_444 30-Mar-11 17:05pm
   
Please tell me what to do to give you the information you need. I don't know how to give you a full dump; exception stack with code line.
Help me help you.
23_444 30-Mar-11 17:11pm
   
> fefefefe() ntdll.dll!7c9032a8() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
Sergey Alexandrovich Kryukov 30-Mar-11 17:20pm
   
Oh-oh... This is not very useful. Will you edit it to one line (such as "to be deleted") first, and then remove?
Please see my update to my Answer.
--SA
23_444 30-Mar-11 17:27pm
   
I will attempt this tomorrow. Thanks for your help on this.
23_444 30-Mar-11 14:23pm
   
No symbols are loaded for any call stack frame. The source code cannot be displayed.
Espen Harlinn 30-Mar-11 15:56pm
   
Good effort, my 5 - downloading and installing the debug symbol files for the OS might help - at least he should be able to make some more sence out his call stack :)
Sergey Alexandrovich Kryukov 30-Mar-11 17:00pm
   
Thank you, Espen.
--SA
23_444 30-Mar-11 16:27pm
   
Thanks for looking. If I had to guess, I'm thinking it is a database issue. The fact that the recordset is put in forward only mode is not good and the fact that it is read only is not good. The recordset definately has to be dynamic and bidirectional. Now the question is why is it switching to this? I think there are odbc issues. My original posting listed this: Driver's SQLSetConnectAttr failed as a possible suspect. Don't know where to go from here though.
The message saying the debugger cannot find a dbg file, is just information, not an error. Your program should run with or without it.

And "Warning: Setting forwardOnly recordset readOnly." is just a warning saying you should have set the readOnly flag in the options when using forwardOnly, and that your record set class does it for you.

Well, that leaves us with no error information at all.

I suggest you trace back to the last point in the code you have control, and start checking parameter values to all system calls you make.
   
v2
Comments
23_444 30-Mar-11 16:11pm
   
I know I'm not helping much but I'm trying. This application has been working for two years without a problem. Now that it is in Visual Studio 2008 it doesn't work in Debug mode. Release mode is fine. Here is where it blows up. After the return statement.

return AfxCallWndProc(pWnd, hWnd, nMsg, wParam, lParam);

The first 3 parameters have addresses while wParam and lParam do not. The error occurs when I attempt to move to the next record. Hope that helps.

AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam) { // special
message which identifies the window as using AfxWndProc if (nMsg ==
WM_QUERYAFXWNDPROC) return 1; // all other messages route through message map

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd);
ASSERT(pWnd != NULL);
ASSERT pWnd==NULL || pWnd->m_hWnd == hWnd);
if (pWnd == NULL || pWnd->m_hWnd != hWnd)
return ::DefWindowProc(hWnd, nMsg, wParam, lParam);

return AfxCallWndProc(pWnd, hWnd, nMsg, wParam, lParam);
}
Niklas L 30-Mar-11 16:20pm
   
If I were you, I would be more interested in examining the last function in your project. Also, you should check if there are any relevant differences in pre-processor directives in debug vs release.
I know I'm not helping much but I'm trying. This application has been working for two years without a problem. Now that it is in Visual Studio 2008 it doesn't work in Debug mode. Release mode is fine. Here is where it blows up. After the return statement. return AfxCallWndProc(pWnd, hWnd, nMsg, wParam, lParam);

The first 3 parameters have addresses while wParam and lParam do not. The error occurs when I attempt to move to the next record. Hope that helps.
AfxWndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam) { // special message which identifies the window as using AfxWndProc if (nMsg == WM_QUERYAFXWNDPROC) return 1; // all other messages route through message map 

CWnd* pWnd = CWnd::FromHandlePermanent(hWnd); 
ASSERT(pWnd != NULL); 
ASSERT pWnd==NULL || pWnd->m_hWnd == hWnd); 
if (pWnd == NULL || pWnd->m_hWnd != hWnd) 
     return ::DefWindowProc(hWnd, nMsg, wParam, lParam); 

return AfxCallWndProc(pWnd, hWnd, nMsg, wParam, lParam); 
}
   
This is the my code. It runs completely through it and then gets into the system stuff I previously posted. I really think the reason is an odbc problem.

void CInfoFView::OnMove(UINT cmdButton) {

	unsigned int nNumRecords = m_pRs->GetNumRecords();
	if (nNumRecords==0){
		return;
	}
	switch (cmdButton){
		case IDC_MOVEPREVIOUS_INFO:
			m_pRs->MovePrev();
			if (!m_pRs->IsBOF()){
				m_ulRecordNumber--;
				if (m_ulRecordNumber==1 && m_New.IsWindowEnabled()){
					m_New.SetFocus();
					SendMessage(DM_SETDEFID,IDC_NEW_INFO);
				}
				break;
			}
			//BOF, else fall through.  Should never get here as button will be disabled
		case IDC_MOVEFIRST_INFO:
			m_pRs->MoveFirst();
			m_ulRecordNumber=1;
			if (m_New.IsWindowEnabled()){
				m_New.SetFocus();
				SendMessage(DM_SETDEFID,IDC_NEW_INFO);
			}
			break;
		case IDC_MOVENEXT_INFO:
			m_pRs->MoveNext();
			if (!m_pRs->IsEOF()){
				m_ulRecordNumber++;
				if (m_ulRecordNumber==nNumRecords && m_New.IsWindowEnabled()){
					m_New.SetFocus();
					SendMessage(DM_SETDEFID,IDC_NEW_INFO);
				}
				break;
			}
			//EOF, else fall through
		case IDC_MOVELAST_INFO:
			m_pRs->MoveLast();
			m_ulRecordNumber=nNumRecords;
			if (m_New.IsWindowEnabled()){
				m_New.SetFocus();
				SendMessage(DM_SETDEFID,IDC_NEW_INFO);
			}
			break;
	}
	DisplayCounters();
	fromRsToCtrls();
	EvaluatePosition();
	//Keeping a record of the current Linker value so other tables can use.
	m_pDoc->setLinker(m_pRs->m_Linker);
	m_pDoc->UpdateAllViews(this);
   
Comments
Albert Holguin 30-Mar-11 18:09pm
   
write your updates as part of the question above, not as solutions, this makes it hard to read...
Look at the call stack and see if you can trace back to which call (from your code, not internal MFC code) caused the exception. Usually you can trace back a bit to find where it occurred, if there isn't enough history there, try placing TRACE statements to narrow down which call is causing that, since its breaking upon reaching a wndproc, i'd suspect that one of the SendMessage() calls is causing the problem (not directly, but something that's using that call), although when using MFC, a lot of the GUI stuff also uses SendMessage() calls internally.
   
I was able to find the problem for the crash. It was the buffer size not being large enough when using this function:

_gcvt_s(szWtBuffer, 20, m_pRs->m_Weight, 10);

It doesn't explain why there would be not problem in Release mode however.

The bigger of the problems is the compiler warnings I am getting that I never used to get before.

Project is working fine, I'm just concerned about the compiler warnings.

Thanks to you who looked at all of this mess.

'Proj.exe': Loaded 'C:\WINDOWS\system32\odbcint.dll', Binary was not built with debug information.Warning: ODBC Success With Info, Driver's SQLSetConnectAttr failedState:IM006,Native : 0,Origin:[Microsoft][ODBC Driver Manager]DBMS: ACCESSVersion: 04.00.0000ODBC Driver Manager Version: 03.52.0000Warning: ODBC Success With Info, String data, right truncated State:01004,Native:5,Origin:[Microsoft][ODBC Microsoft Access Driver]'Proj.exe': Loaded 'C:\WINDOWS\system32\expsrv.dll', Cannot find or open a required DBG file.Warning: Setting forwardOnly recordset readOnly.
   
Comments
Albert Holguin 4-Apr-11 11:51am
   
you were probably overwriting a piece of memory that wasn't important... so you didn't notice negative consequences...
23_444 4-Apr-11 11:52am
   
Thanks, that makes sense.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900