Solved

an unhandled exception was encountered during a user callback

Posted on 2014-12-17
36
1,832 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 31

Accepted Solution

by:
Zoppo earned 333 total points
ID: 40504871
Hi rickhill11,

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

ZOPPO
0
 
LVL 34

Expert Comment

by:sarabande
ID: 40504876
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
ID: 40506078
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
Online Training Solution

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action. Forget about retraining and skyrocket knowledge retention rates.

 

Author Comment

by:rickhill11
ID: 40506146
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
ID: 40506151
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
ID: 40506159
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 31

Expert Comment

by:Zoppo
ID: 40506649
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 34

Expert Comment

by:sarabande
ID: 40506661
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
ID: 40506858
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
ID: 40506886
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 34

Expert Comment

by:sarabande
ID: 40506916
"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 34

Expert Comment

by:sarabande
ID: 40506946
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
ID: 40507012
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 34

Expert Comment

by:sarabande
ID: 40507077
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 31

Expert Comment

by:Zoppo
ID: 40507093
>> 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 34

Expert Comment

by:sarabande
ID: 40507099
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
ID: 40507350
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 31

Expert Comment

by:Zoppo
ID: 40507421
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
 
LVL 34

Expert Comment

by:sarabande
ID: 40507523
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
ID: 40508364
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
ID: 40508393
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
ID: 40508400
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
ID: 40508403
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 34

Expert Comment

by:sarabande
ID: 40508655
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 34

Expert Comment

by:sarabande
ID: 40508659
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 31

Expert Comment

by:Zoppo
ID: 40508688
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
ID: 40509031
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 31

Expert Comment

by:Zoppo
ID: 40509102
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
ID: 40509139
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
ID: 40509143
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 31

Assisted Solution

by:Zoppo
Zoppo earned 333 total points
ID: 40509212
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
ID: 40509646
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
ID: 40510745
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 34

Assisted Solution

by:sarabande
sarabande earned 167 total points
ID: 40510873
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
ID: 40517300
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
ID: 40517301
Again, thanks for taking the time to answer.

Rick
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

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.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

As more and more people are shifting to the latest .Net frameworks, the windows presentation framework is gaining importance by the day. Many people are now turning to WPF controls to provide a rich user experience. I have been using WPF controls fo…
After several hours of googling I could not gather any information on this topic. There are several ways of controlling the USB port connected to any storage device. The best example of that is by changing the registry value of "HKEY_LOCAL_MACHINE\S…
The viewer will learn how to user default arguments when defining functions. This method of defining functions will be contrasted with the non-default-argument of defining functions.
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.

733 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