Solved

an unhandled exception was encountered during a user callback

Posted on 2014-12-17
36
1,442 Views
Last Modified: 2014-12-24
I have a very simple Dialog project, that randomly, about 1 out of 10 times, on invocation, throws the exception

an unhandled exception was encountered during a user callback

The only thing different about this app is that long after I stated development, I changed the character set from UNICODE to Multibyte.  I'm pretty certain that this is related to the problem as the debugger stops in a windows library that is in a UNICODE section.  So, I am thinking a linker or other switch, but I can't find it.

Any help will be greatly appreciated.
0
Comment
Question by:rickhill11
  • 19
  • 10
  • 7
36 Comments
 
LVL 30

Accepted Solution

by:
Zoppo earned 333 total points
Comment Utility
Hi rickhill11,

could you post the callstack where the program stops when the excpetion is thrown?

ZOPPO
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
can you reproduce the crash in debug configuration? if yes, you should start the program from visual studio and watch the output window which exception code is thrown. if you are right that it is a string issue, the exception probably is 'access violation' 0xc0000005'.

if you know the code you can make a debug setting (in Debug- Exceptions ... - Win32- Exceptions) such that the debugger stops the execution when the exception was thrown rather than when it finds out that it was not handled. doing so, the debugger would stop exactly at the wrong statement where the crash happened.

if it happens in release configuration only, you nevertheless should get a crash message where you could see the exception code. if there is no message you may check the event viewer or start the program in visual studio and check the output window. depending on the exception it might be necessary to enable your project to handle SEH exceptions additionally to c++ exceptions. SEH exceptions are windows exceptions. if you know which exception is thrown and the program could handle it, you could add try-catch blocks to your code in order to narrow down the issue until you found the wrong code.

Sara
0
 

Author Comment

by:rickhill11
Comment Utility
Have some new information.  When the exception is thrown, I get

Wintdll.pdb not loaded

Original location C:\Windows\SysWOW64\ntdll.dll

When I look into that directory, the file is there.

Without that stuff, it is impossible to backtrace the stack.

Additional problem, probably related, but there was a function that was not behaving as it should.  I'm dealing with somewhat large test files, so I tried to get clever with something like
if(xxxx==535)
int aa=0;
aa+=10
}, and put a breakpoint on the aa+=10.  When I run this without a breakpoint, it proceeds through the code normally----even though it is not doing what I wanted, the steps through the code seem to be normal.  If I enable the breakpoint, than when I hit F10 to step through, it relaunches the original dialog.

Rick
0
 

Author Comment

by:rickhill11
Comment Utility
Did a breakpoint, and it failed on

      if (m_bVistaStyle == TRUE)
      {
            ApplyOFNToShellDialog();
            HRESULT hr = (static_cast<IFileDialog*>(m_pIFileDialog))->Show(m_ofn.hwndOwner);
            nResult = (hr == S_OK) ? IDOK : IDCANCEL;
      }
0
 

Author Comment

by:rickhill11
Comment Utility
The other thing that might be germane, is that when I created the CDialog variables, I used CStrings rather than the proffered variable types.  Is this a problem----I've been away from VC++  VS2012 for quite a while doing other things, and I'm pretty sure that I've done this before, but maybe not.

Thanks, Rick
0
 

Author Comment

by:rickhill11
Comment Utility
One last thing.  I just went to the Wizard, and created a couple of variables, and for the CEdits, was offered a CString option.  Maybe I am losing my mind, but know for a fact that when I created this dialog, and was putting controls on it, it didn't offer the CString option.

Rick
0
 
LVL 30

Expert Comment

by:Zoppo
Comment Utility
ok, that gets a bit confuzing now.

First about the last thing: For edit controls the ClassWizard can create variables of different types depending on the selected Category (numeric Value types like int or double, CString or Control type (CEdit). This IMO didn't change since at least VC++ 6.0.

About the message regarding Wintdll.pdb IMO you don't need to worry, it just means the debugger wasn't able to load debug info for ntdll.dll, it's very unlikely this can somehow be the cause for problems.

General questions:

1. Could it be you're using a RELEASE build for debugging? This could explain the breakpoint-not-hit behavior because due to optimization i.e. the code within the if (xxxx==535) isn't built into the binary because the compiler detects it doesn't do anything.

If so you should first try to reproduce the problem in a DEBUG build. Only if it isn't reproducable in a DEBUG you should debug in RELEASE, but to do this any optimization options should be (temporary) turned OFF.

2. Does the exception occur befor your application is started at all (so i.e. before you CWinApp derived classes InitInstance is called)? If not you should see at least information about where it occurs within your code. It could be the debugger initially shows the call stack from a thread which is not the main thread - you can open a debugger-window which shows all running threads where you can switch the current context by doubleclick to the Main Thread.

ZOPPO
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
to add to above comment:

Wintdll.pdb not loaded
as Zoppo said you can ignore it. the debugger didn't find a suitable debug database for one of the dll's. you could switch off those messages in the output window (by right-clicking on it) since I never experienced a system where all possible pdb files could be located.  

Additional problem, probably related, but there was a function that was not behaving as it should.

I don't think it is related. and it is not quite clear what is the different behavior when breaking. if we assume that the crash occurs because of some memory corruption (what is very likely if it occurs only sometimes), breakpoints of course may have an influence which part of the memory get corrupted.

if(xxxx==535)
you better use conditional breakpoints instead of adding meaningless code. create a breakpoint and then right-click on it and select condition. then enter 'xxxx==535' as a condition.

Did a breakpoint, and it failed on ...
where did it fail? at ApplyOFNToShellDialog(); or at  (static_cast<IFileDialog*>(m_pIFileDialog))->Show(m_ofn.hwndOwner);

you may set a breakpoint at both. check if the m_plFileDialog is not NULL. if you enter  (IFileDialog*)m_pIFileDialog in the watch window, you also would find out whether the cast worked. the debugger would show a valid HWND handle for the dialog.

when I created the CDialog variables, I used CStrings rather than the proffered variable types.  Is this a problem
no. CString is the valid type for static field text or edit field text. probably you mixed it up with the member type of the control (not the text value). these types are CEdit or CStatic.

Did you know more which exception code is thrown? check the output window after crash.

Sara
0
 

Author Comment

by:rickhill11
Comment Utility
Did not know about conditional waypoints, thanks that will help in the future.

The failure "First-chance exception at 0x756D4B32 (KernelBase.dll) in SortAbsences.exe: 0x000006BA: The RPC server is unavailable." occurs at

            HRESULT hr = (static_cast<IFileDialog*>(m_pIFileDialog))->Show(m_ofn.hwndOwner);
Hitting F11 on this line takes me into

OPENFILENAME& CFileDialog::GetOFN()
{
      return *m_pOFN;
}

Which seems to return back to the HRESULT line.  Hitting F11 again immediately throws the exception.

This code executes when a particular button is pressed, and just in case you are interested, here is the OnButton... code up to the failure point.

void CSortAbsencesDlg::OnClickedButtonInputFile()
{
      // TODO: Add your control notification handler code here
      CString Inf;
      int iIndex;
      bool bUpdateOutFileName=false;
      CFileDialog Dlg(true,_T(".txt"),NULL,NULL,_T("BAS Files (*.txt)|*.txt|All Files (*.*)|*.*||"));
      Dlg.m_ofn.lpstrInitialDir=(INITIAL_DIRECTORY);
      UpdateData(true);
      if(Dlg.DoModal()==IDOK){

INITIAL DIRECTORY is a #define INITIAL_DIRECTORY "c:\\schedules\\BAS"

I'm pretty sure that with the multibyte char set, the _T is not required, but is harmless.

Thanks again for you help
0
 

Author Comment

by:rickhill11
Comment Utility
To answer the general questions.
1.  This is a debug version.
2.  Didn't know about the thread, will try that.

The First Exception is thrown when I click on a BROWSE button that is supposed to open a CFileDialog, see above.

If I am reading the call stack correctly, the error seems to occur on

            case WM_INITDIALOG:
                  {
                        DWORD dwStyle;
                        CRect rectOld;
                        CWnd* pWnd = CWnd::FromHandle(hWnd);
                        _AfxPreInitDialog(pWnd, &rectOld, &dwStyle);
                        bCallDefault = FALSE;
                        lResult = CallWindowProc(oldWndProc, hWnd, nMsg, wParam, lParam);
                        _AfxPostInitDialog(pWnd, rectOld, dwStyle);
                  }

Again, thanks for your help!
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
"First-chance exception at 0x756D4B32 (KernelBase.dll)
a first chance exception not necessarily leads to a crash.  it is handled by a try-catch block and in most cases it is not thrown again. first-chance exception often happen if some system function has to evaluate some stored pointers which may have got invalid in the meantime.

0x000006BA: The RPC server is unavailable."


this exception has some other reasons. see

http://www.winhelponline.com/blog/fix-sfc-error-0x000006ba-rpc-unavailable/
or
https://www.youtube.com/watch?v=A-TuLKlKrds

are you sure that this exception causes the crash?

I would assume that the statement m_pOFN pointer could be the reason. if m_pOFN is NULL or is pointing to some invalid memory, the crash happens when some pointer members of the OPENFILE struct were used by the dialog.

you may check the pointer with the debugger.

Sara
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
If I am reading the call stack correctly, the error seems to occur on
which statement makes the debugger break? did you try to use 'ignore' when the debugger message arises? I would assume the real crash happens after the exception was thrown (and if the crash description of your original post still is valid, it might crash only occasionally).

Sara
0
 

Author Comment

by:rickhill11
Comment Utility
Until I added the BREAKPOINT trying to trap a logic error, the program never broke, it simply would throw an exception or two, and otherwise perform normally.

When I added the BREAKPOINT to help discover my own logic error, when the breakpoint was hit, and I hit F10, the program jumped to somewhere else in the code, and instead of reading the contents of a file, and evaluating same, it would bring up the main CDialog again.  Weird.

No one has commented on my, on the fly, change from Unicode to Multibye.  I did this with a single click on the Configuration Properties->General->Character Set.  Does this mean that I am chasing a chimera when I think along these lines?  When I created the program, I foolishly left most of the defaults in place, so the checkbox to use UNICODE libraries was almost certainly checked, and I haven't found a place to uncheck that selection.  Another chimera?

On a lark, I ran the program without debugging CTL F5, and it crashed in about the same place.  Sometime later today, I'll revisit this, and see what I can find, and see if I can get more information for you.


Thanks, Rick
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
Does this mean that I am chasing a chimera when I think along these lines?  
not necessarily, but from your other observations we don't have any hint that string conversion may have caused the issues you encounter.

I did this with a single click on the Configuration Properties->General->Character Set.  
as long as you always used TCHAR, LPCTSTR, LPTSTR, CString, _T("literal") and not char, LPCSTR, LPSTR, "literal" it should be fine. the compiler would have complained if you would try to use a char pointer where now a wchar_t pointer is required. of course, it could be that some of your string buffers are too short or that you do some formatting with %s where now wide characters were used for input, but we don't have any indication for this.

Dlg.m_ofn.lpstrInitialDir=(INITIAL_DIRECTORY);
can you find out how the INITIAL_DIRECTORY is defined? it should be a wide string.

Sara
0
 
LVL 30

Expert Comment

by:Zoppo
Comment Utility
>> No one has commented on my, on the fly, change from Unicode to Multibye

This is because usually changing from UNICODE to MB or ASCII is no problem as long as you don't direct access strings using char-pointers. Usually MFC classes or WinAPI functions exist in two versions (one for UNICODE, one for ASCII) and use the appropriate one depending on the UNICODE define.

BTW, a trivial question: Did you already try to do a clean re-build? Sometimes VS doesn't correctly recognize something needs to be re-compiled after compiler- or linker-settings were changed.

About your last comment: When you start with CTRL-F5, does it even only crash from time to time (your wrote about 1 out of 10 times in the question)? Or does it crash always?

And another question: Do you use some of the newer MFC dialog controls? These are controls which were first introduced with a feature pack of VS 2008, later as built-in with VS 2010, like i.e. MFC EditBrowse/MenuButton/ShellTree/...  controls? IIRC some of these control can't be used without UNICODE.

ZOPPO
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
when the breakpoint was hit, and I hit F10, the program jumped to somewhere else in the code
that could happen when an exception was thrown in the statement where you hit F10. try to using F11 instead of F10 for every non-trivial statement. the exception can be thrown in a constructor or system function. always watch the output window if somewhat special is happening.

Another chimera?
no. beside you didn't operate with a valid build or are using a wrong (old) debug database. the latter may happen if you once moved the project to a different location but didn't change some paths pointing to the old project. however, if you can set breakpoints in the code, the sources you were debugging are the right ones. the debugger will find out if sources are old and give a warning.

Sara
0
 

Author Comment

by:rickhill11
Comment Utility
There are a couple of places where I use f(char *cp)
{...
   *(cp+...)
} however I don't think that there is anything up to the point where it is crashing.  When I get back to the office will check.

When you say "Clean Rebuild", do you mean a "Clean" followed by a rebuild.  I've "rebuilt" the solution, but did not precede with a "Clean."
 
With all the exceptions turned on, it does something every time.  Before I turned them all on, it was about 1 out of 10, or even 1 out of 20.  Also, it didn't crash, it would simply throw an exception, and, if I chose to continue, it would continue just fine.

I'm using CButtons, CEdits, CStatic, and that is all.
0
 
LVL 30

Expert Comment

by:Zoppo
Comment Utility
ok, 'Rebuild' is ok, it's just the same as 'Clean' followed by 'Build'.

And hm - above you told it crashs when starting with CTRL-F5, now you tell it doesn't crash, difficult ...

Do you get any exception which is not a first-chance exception? If so could you please post a screenshot ot the debugger output and the complete call stack?

If you have only first-chance exceptions you IMO can simply ignore them and, if they're annoying, configure the debugger to not stop if such an exception was thrown.

ZOPPO
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 
LVL 32

Expert Comment

by:sarabande
Comment Utility
If you have only first-chance exceptions you IMO can simply ignore them and, if they're annoying, configure the debugger to not stop if such an exception was thrown.
yes. you should turn-off all first-chance-exceptions which run fine after continue because they were handled by windows.

in my opinion only 0xc0000005 'access violation' is an exception where the program would not recover from. so turn-off all exceptions beside 0xc0000005 and try to reproduce the crash. if it happened in the debugger and if it is 'access violation' then, the debugger would break exactly at the statement which caused the exception. if you check the variables of the statement you should find out the wrong pointer variable and probably the reason why it crashed. if it is access violation (see output window) but the debugger didn't break, the project probably is not enabled to catch SEH exceptions.
set the option 'enable c++ exceptions' to 'yes with SEH exceptions' (you find the setting at 'configuration properties - c/c++ - code generation') and rebuild your program.

if the program doesn't crash in debug mode at all, you should enable the SEH exceptions for release configuration and add try-catch blocks (with a messagebox call in the catch part) to functions to narrow down where the crash happens. you would begin with the handler function that handles click on the 'Browse' button. it should show the message when it crashes or it is not the right function. if you got the message make the try - block smaller and repeat the actions. do that until the try block contains only one statement which either is the bad statement or calls into another function where you could repeat the procedure.

Sara
0
 

Author Comment

by:rickhill11
Comment Utility
Will do this one a screen at a time, as the last time my computer locked up and had to be shutdown.

Disabled(is this the correct term?) all of the exceptions other than 0x0...5---and we're back to somewhere around 1 in 10 or even 20.

The exception comes in

      if (m_bVistaStyle == TRUE)
      {
            ApplyOFNToShellDialog();
----------------->            HRESULT hr = (static_cast<IFileDialog*>(m_pIFileDialog))->Show(m_ofn.hwndOwner);
            nResult = (hr == S_OK) ? IDOK : IDCANCEL;
      }
0
 

Author Comment

by:rickhill11
Comment Utility
Well, I'm still computing this time.  The above exception was caused in the DoModal() call.

On the off chance that setting the starting directory was the culprit, I commented that line out, and the results are about the same: 1 in 10-20; actually I haven't gotten past 10 in a long time.

Just to be clear,

BOOL CSortAbsencesDlg::OnInitDialog()
{
      CDialogEx::OnInitDialog();

      // Add "About..." menu item to system menu.

      // IDM_ABOUTBOX must be in the system command range.
      ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
      ASSERT(IDM_ABOUTBOX < 0xF000);

      CMenu* pSysMenu = GetSystemMenu(FALSE);
      if (pSysMenu != NULL)
      {
            BOOL bNameValid;
            CString strAboutMenu;
            bNameValid = strAboutMenu.LoadString(IDS_ABOUTBOX);
            ASSERT(bNameValid);
            if (!strAboutMenu.IsEmpty())
            {
                  pSysMenu->AppendMenu(MF_SEPARATOR);
                  pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
            }
      }

      // Set the icon for this dialog.  The framework does this automatically
      //  when the application's main window is not a dialog
      SetIcon(m_hIcon, TRUE);                  // Set big icon
      SetIcon(m_hIcon, FALSE);            // Set small icon

      // TODO: Add extra initialization here


      csBidPeriods.Format("%s\\BidPeriods.txt",INITIAL_DIRECTORY);

      char buffer[128];
      EstimateBidPeriod(buffer);
      BidPeriod.Format("%s",buffer);
      bNormalAbsence=true;
      UpdateData(false);

      FBidPeriods=fopen((LPCTSTR)csBidPeriods,"r");
      SearchBidDateRange();

      return TRUE;  // return TRUE  unless you set the focus to a control
}

SearchBidDateRange is very benign

void CSortAbsencesDlg::SearchBidDateRange()
{
      char line[255];
      if(!FBidPeriods)return;
      rewind(FBidPeriods);
      BeginDate.Format("");
      EndDate.Format("");
      UpdateData(false);
      while(fgets(line,128,FBidPeriods)){
            if(feof(FBidPeriods))return;
            if(line[0]=='#')continue;
            if(strncmp(line,(LPCTSTR)BidPeriod,5))continue;
            BeginDate.Format("%-8.8s",&line[6]);
            EndDate.Format("%-8.8s",&line[15]);
            UpdateData(false);
            break;
      }
      UpdateData(true);
      return;
}

Then there is the button click
where INITIAL_DIRECTORY is

#define INITIAL DIRECTORY _T("c:\\schedules\\BAS")

I've tried it both with and without the _T

void CSortAbsencesDlg::OnClickedButtonInputFile()
{
      // TODO: Add your control notification handler code here
      CString Inf;
      int iIndex;
      bool bUpdateOutFileName=false;
      CFileDialog Dlg(true,_T(".txt"),NULL,NULL,_T("BAS Files (*.txt)|*.txt|All Files (*.*)|*.*||"));
      Dlg.m_ofn.lpstrInitialDir=(INITIAL_DIRECTORY);
      UpdateData(true);
      if(Dlg.DoModal()==IDOK){
            InFileName=Dlg.GetPathName();
            UpdateData(false);
            if(!OutFileName.IsEmpty()){
                  if(AfxMessageBox(_T("Update Output File Name"),MB_YESNO)==IDYES){
                        bUpdateOutFileName=true;
                  }
            }else bUpdateOutFileName=true;
      }
      if(bUpdateOutFileName){
            iIndex=InFileName.Find(_T(".txt"));
            if(iIndex>0){
                  OutFileName=InFileName.Left(iIndex);
                  OutFileName=OutFileName+_T(".dat");
                  UpdateData(false);
            }else{
                  AfxMessageBox(_T("Unable To Format Output File Name Due To Missing \".txt\" In Input File Name"));
            }
      }
      iIndex=InFileName.Find(_T(".txt"));
      if(iIndex>0){
            TempFileName=InFileName.Left(iIndex);
            TempFileName=TempFileName+_T(".tmp");
            UpdateData(false);
      }else{
            AfxMessageBox(_T("Unable To Format Temporary File Name Due To Missing \".txt\" In Input File Name"));
      }

}

The code is so benign, I am having trouble wrapping my head around all the problems.

Thanks again, Rick
0
 

Author Comment

by:rickhill11
Comment Utility
OK, enabled SEH Exceptions, and the following two lines had a green vertical bar in the very left column.

      CFileDialog Dlg(true,_T(".txt"),NULL,NULL,_T("BAS Files (*.txt)|*.txt|All Files (*.*)|*.*||"));
      Dlg.m_ofn.lpstrInitialDir=(INITIAL_DIRECTORY);

Don't have a clue what that means.  Did a main thread stack trace, and the failure occurred at the same place

      if (m_bVistaStyle == TRUE)
       {
             ApplyOFNToShellDialog();
 ----------------->            HRESULT hr = (static_cast<IFileDialog*>(m_pIFileDialog))->Show(m_ofn.hwndOwner);
             nResult = (hr == S_OK) ? IDOK : IDCANCEL;
       }

Thanks again, Rick
0
 

Author Comment

by:rickhill11
Comment Utility
Also tried without the fancy CFileDialog, just used CFileDialog Dlg(true)

It still threw the same error anywhere from 1 in 3 to 1 in 10.

Rick
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
char buffer[128];
first you should increase all buffers like the one above such that it is absolutely sure that it doesn't get an overflow and initialize them;

char buffer[1024] = { '\0' };

Open in new window

next is that youu may omit all formatting by using sprintf or Format function and use strcat_s or std::ostringstream which both are safe regarding buffer overflow. generally, avoid unsecure strcpy, strcmp and use std::string for char and std::wstring or CString for wchar_t.

instead of using a macro INITIAL_DIRECTORY use a static variable or member:

static char INITIAL_DIRECTORY[] = "....";

Open in new window


the green vertical bar in visual studio editor is only a marker of the 'intellisense' that you recently made a change.

the statement where the debugger stopped is indeed the statement where it crashes, but, since the crash happens only sometimes, it is not the reason for the crash, but it crashes because the memory was corrupted before somehow. i would assume it is either because of a buffer overflow (somewhere wrote beyond buffer size) or use of a not initialized buffer (which sometimes doesn't matter and sometimes crashes) or use of a local buffer which has been already freed but works as long as the freed memory was not reused. if you post all your source we might find the bug.

Sara
0
 
LVL 32

Expert Comment

by:sarabande
Comment Utility
can you check (by F12) what type  Dlg.m_ofn.lpstrInitialDir is?

is it LPSTR or LPTSTR?

if the latter the INITIAL_DIRECTORY also must be a wide char string, that means you have to use _T macro.

if the type is LPSTR, check the types of the arguments you are passing to constructor of CFileDialog. i would assume then it is also LPCSTR and not LPCTSTR what means that you would need to omit the _T macro when calling the constructor.

Sara
0
 
LVL 30

Expert Comment

by:Zoppo
Comment Utility
IMO you should try what happens if you remove this line:

       Dlg.m_ofn.lpstrInitialDir=(INITIAL_DIRECTORY);

At http://msdn.microsoft.com/en-us/library/43xtah3y.aspx you can find this:
Windows Vista style file dialogs do not support certain members and flags of the CFileDialog. As a result, these will have no effect.

The following is a list of the members that are not supported by Windows Vista:
 -   lpstrInitialDir
 ...
So using this member at best has no effect ...

ZOPPO
0
 

Author Comment

by:rickhill11
Comment Utility
Commented out the set initial directory lines.  

Interestingly, the failure occurred in a new place and pView is NULL at that point, so it is hard to figure out
how it got past pView!=NULL!

      CView* pView = GetActiveView();
---------->      if (pView != NULL && pView->IsKindOf(RUNTIME_CLASS(CPreviewViewEx)) && m_dockManager.IsPrintPreviewValid())
      {
            CRect rectClient = m_dockManager.GetClientAreaBounds();
            pView->SetWindowPos(NULL, rectClient.left, rectClient.top, rectClient.Width(), rectClient.Height(), SWP_NOZORDER  | SWP_NOACTIVATE);
      }

Rick
0
 
LVL 30

Expert Comment

by:Zoppo
Comment Utility
In which function does this happen?
Do you see a call stack now?
What kind of application (Dialog, SDI, MDI) is it?
0
 

Author Comment

by:rickhill11
Comment Utility
I suspect that I did something wrong above, as subsequent failures occurred at the same place.

I'm basically an old K&R C programmer, so the notion of keeping track of buffers, preventing overflow, etc., is pretty second nature.  Tried the initialization to {'\0'} for all character buffers, and still it breaks.  Don't have time this morning to try to other string stuff----this is a favor that I am doing for a friend, but boss still expects me to come to work!  Imagine that!

The file won't attach, so the dropbox link to the zip file is:
 
https://dl.dropboxusercontent.com/u/24768047/SortAbsences1.zip

To cause the exception, launch the app, select BROWSE for the input file, and then cancel all.  Or, you can select a random text file, and then cancel.  I believe that I've sufficiently guarded against errata in the data to keep it from blowing up the program.  I can't provide the text files that I am using as they contain personal information for employees.  Sorry!

Thanks again, Rick
0
 

Author Comment

by:rickhill11
Comment Utility
I also need to ask, what is the big deal about initializing buffers?  It has a sort of appeal in terms of a clean solution, but, in the real old days, we never bothered, primarily because we were dealing with program size limits, and CPU time limits, and we just didn't want to waste either.  Just curious!
0
 
LVL 30

Assisted Solution

by:Zoppo
Zoppo earned 333 total points
Comment Utility
Hm - unfortunateley I can't reproduce. I compiled it as 32-Bit DEBUG with VS 2013 (that's the only one I can test with) on Windows7 64 Bit and I was able to click/cancel Browse at least 50 times without problems.

One thing I found is a compile warning:
1>c:\program files (x86)\microsoft visual studio 12.0\vc\atlmfc\include\afx.h(38): warning C4996: 'MBCS_Support_Deprecated_In_MFC': MBCS support in MFC is deprecated and may be removed in a future version of MFC.
1>          c:\program files (x86)\microsoft visual studio 12.0\vc\atlmfc\include\afx.h(33) : see declaration of 'MBCS_Support_Deprecated_In_MFC'

Open in new window

So maybe it's anyway not such a good idea to turn from UNICODE to MBCS - could you tell us why you change this at all?

ZOPPO
0
 

Author Comment

by:rickhill11
Comment Utility
Remember that I am a K&R C Programmer thrust into this environment, and I am not a professional programmer any longer.  So, I was just trying to make it as simple and K&R like as possible.
0
 

Author Comment

by:rickhill11
Comment Utility
Thanks to you both for you help.  The next to last thing that I tried was to increase the buffers to unreasonable sizes.  An fgets(...,128,...) got a 1204 byte buffer for instance.  That didn't work, then I thought about Zoppo's comment about being unable to reproduce on his computer, and I wondered if I was seeing the first sign of a degrading computer.

So, I moved the entire solution to my desktop, and am now unable to reproduce the error.  

Any thoughts?

BTW, I am leaving this open for a short while just in case the problem recurs.
0
 
LVL 32

Assisted Solution

by:sarabande
sarabande earned 167 total points
Comment Utility
The next to last thing that I tried was to increase the buffers to unreasonable sizes.
you may turn it back and check whether the problem comes up again.

as told, it looked like a buffer overflow issue, and K&R doesn't mean you may not care for buffer boundaries.

Sara
0
 

Author Comment

by:rickhill11
Comment Utility
Moved the code back to my laptop, and it started breaking again.  A Google search suggested a mismatch between the build version, and the libraries being linked.  I was very doubtful because that is a level of configuration that I just wouldn't get involved in without someone's specific advice.  Anyway, somewhere along the line some of the link libraries seemed to be  non-debug/release versions.  Go figure!  I did intentionally make a change from Unicode to MBCS, and maybe I did something there.  

Anyway, thanks again for all your help.

Rick
0
 

Author Closing Comment

by:rickhill11
Comment Utility
Again, thanks for taking the time to answer.

Rick
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

When writing generic code, using template meta-programming techniques, it is sometimes useful to know if a type is convertible to another type. A good example of when this might be is if you are writing diagnostic instrumentation for code to generat…
This article shows you how to optimize memory allocations in C++ using placement new. Applicable especially to usecases dealing with creation of large number of objects. A brief on problem: Lets take example problem for simplicity: - I have a G…
The viewer will be introduced to the technique of using vectors in C++. The video will cover how to define a vector, store values in the vector and retrieve data from the values stored in the vector.
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now