Debug Error using Visual C++ 6.0

I am getting the following error message while debugging my application using Visual C++ 6.0 interface. Can anyone help me out how to solve this issue.

"user break-point called from code at 0x7c90120e"
 
Thanks in advance
prashanth agsoftware engineer Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sarabandeCommented:
"user break-point called from code at 0x7c90120e"
a user breakpoint was issued when the condition of a debug assertion happens to be false at runtime. the debugger would stop execution at the assertion statement and ask you what to do next. if you choose 'break' or 'retry' it would step to the code where the assertion was thrown.

this normally is mfc source code where you see code like

ASSERT(hWnd != NULL); 

Open in new window

or

if (pos >= length)
{
      ASSERT(FALSE);
}

Open in new window


you may look at the function name where the statement  is and analyze the fail condition and sometimes you may find out what went wrong by this. if not, you look at the call stack window which shows the last functions called. the function where the user break happened is on the top. you then should look deeper until you find a function which was in your code rather than mfc or windows. by evaluating the arguments you probably could find out what has caused the failure and how you can fix it. note, a debug assertion sometimes is only a warning. that means if you ignore the break and continue, it might be possible that it worked beside of the assertion. however, you should do that only if you know what was wrong and that you can safely ignore it for the moment.

for your information: you also can set assertion statements in your code if you want to stop in case of false conditions. debug assertions will not be executed in release configuration but could help while developing in debug mode.

Sara
sarabandeCommented:
hi,
 yes in code "ASSERT(FALSE); " was  there .

 if ( NULL == pParentWnd )
    {
       // something is wrong; MFC should be able to find a main window.
       ASSERT(FALSE);
       return FALSE;
    }

 what i need to do plz explain me once .

the assertion is thrown, because your current window doesn't have a parent window. that could happen if - for example - you created a child dialog in your current dialog and forgot to pass the 'this' pointer as argument to the dialog constructor.

you may do the following steps:

(1) when you stopped in the debugger at the ASSERT startement, open the call stack window. you will find the call stack window either in a tab beside 'output', 'breakpoints' or by opening the 'debug - windows' sub menu. if I remember rightly you also could type CTRL+K to open the call stack window.
(2) if the stack window is open you will see a list of entry points to function calls. if you click on the top entry you will navigate to the ASSERT statement where the user break happened. the ASSERT statement is in a mfc function and if you click again into the call stack window but one entry below you will come to the function that was one step above in the call hierarchy, what means you see the statement that calls function where you have the assertion.
(3) if you look at the next callers in the call stack window you finally will see a function which was not a mfc function but a member function of one of your classes, perhaps in YourDialog::OnInitDialog or similar.
(4) click at the entry and post the code around that statement here in a code window (use the CODE tags and post the text from clipboard between  [ code ] and [ /code ].

Sara

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
prashanth agsoftware engineer Author Commented:
(call stack unavailable while child is running)

Open in new window

prashanth agsoftware engineer Author Commented:
// CEPCSApp construction

CEPCSApp::CEPCSApp()
{
	// TODO: add construction code here,
	// Place all significant initialization in InitInstance
}

/////////////////////////////////////////////////////////////////////////////
// The one and only CEPCSApp object

CEPCSApp theApp;

/////////////////////////////////////////////////////////////////////////////
// CEPCSApp initialization

BOOL CEPCSApp::InitInstance()

{
	if (!AfxSocketInit())
	{
		AfxMessageBox(IDP_SOCKETS_INIT_FAILED);
		return FALSE;
	}

	AfxEnableControlContainer();

	// Standard initialization
	// If you are not using these features and wish to reduce the size
	//  of your final executable, you should remove from the following
	//  the specific initialization routines you do not need.

Open in new window

sarabandeCommented:
call stack unavailable while child is running
you have to leave the assertion window with 'RETRY' or 'BREAK'. when the debugger stops at the ASSERT(FALSE) statement , the call stack window is available and you can find out  which of your member functions have caused the assertion.

Sara
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.