• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 503
  • Last Modified:

Losing battle with exception 0xC0000005

Hi:
   I'm not sure exactly what my problem is and am completely baffled as to what could have caused my problem.  Basically, around two weeks ago, I would run an application I had wrote and as soon as I moved the mouse on the menu part of an SDI/MDI application the app would crash with our famous exception 0xC0000005.  
   At first I assumed that I was doing something wicked but if I create a default SDI application and move the mouse into the menu part of the control bar I get the above exception.    In addition, many times Windows Explorer crashes.  Also, sometimes W98 won't even shut down completely!
   My question is "What are my options right now?".  I really don't want to trash my system and reinstall W98, but I feel this may be my only option.  
  I don't know if a Stack Trace will help, but here it is:
VERSION! bfe714a8()
KERNEL32! bff958f8()
COMCTL32! bfe93f20()
KERNEL32! bff958f8()
CWnd::WindowProc(unsigned int 512, unsigned int 0, long 65623) line 1586 + 26 bytes
CControlBar::WindowProc(unsigned int 512, unsigned int 0, long 65623) line 470 + 20 bytes
AfxCallWndProc(CWnd * 0x00771e20 {CToolBar hWnd=0x00000e34}, HWND__ * 0x00000e34, unsigned int 512, unsigned int 0, long 65623) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00000e34, unsigned int 512, unsigned int 0, long 65623) line 368
AfxWndProcBase(HWND__ * 0x00000e34, unsigned int 512, unsigned int 0, long 65623) line 220 + 21 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()

   Glenn
0
GlennDean
Asked:
GlennDean
  • 8
  • 4
  • 2
  • +4
1 Solution
 
jkrCommented:
You seem to have a version problem with your system DLLs. The last call to 'CWnd::WindowProc()' is a WM_MOUSEMOVE', and the function itself calls 'DefWindowProc()' to handle it. The rest seems to be just the delegation to the common control DLL...

Any major installations recently? :o)
0
 
GlennDeanAuthor Commented:
Hi jkr:  
  Around two weeks ago (I'm not sure if my problems occurred before or after the installation) I installed IomegaWare's Zip drive software.  That's the only new thing on my system.  I uninstalled that software today and the problem still exists.
  You mentioned System Dll - what in the stack trace indicates there's a problem with my DLLs?  I've been nervous of doing the following but do you think it might help to uninstall VC++ 6.0 and then reinstall??  I don't really know if the uninstall will erase all the programs I've written or not.  My guess is the uninstall program will not delete any of my DLLs because all kinds of other applications use them (for example Visual Basic 6.0 and Visual J++).  
   Glenn
0
 
FengYuanCommented:
Check in assembly code to see that's the exact address causing the access vialotion. If it's system DLL problems, check the version and try to install the right version. But if other program runs fine, and only your program has problem, the problem may be in your program.

If just can't figure out, try to add exception handling to your code to avoid the GPF.

Also, try to install the latest service pack of MSVC, which may have fixed the problem.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
GlennDeanAuthor Commented:
Hi FengYuan:
   To the best of my knowledge, the problem appears not to be my program.  I create a default SDI app and the exception occurs.  To try to isolate the problem, I have no other applications running except VC++ 6.0.
   I have looked at the assembly code when the exception occurs, but the address is either 0xbff768a0 or 0x887aa608.  To the best of my knowledge, those virtual addresses are "System addresses".  I say that because the upper 2 Gig of memory is for the OS, lower 2 Gig is for Glenn ?????

   Glenn

   Glenn
0
 
jkrCommented:
>>You mentioned System Dll - what in the stack trace
>>indicates there's a problem with my DLLs?  

I can't think of anything else. The Iomega setup SW might have replaced a system DLL, and these are not restored upon uninstall. The the version numbers of the DLLs involved (dumpbin /version <DLL>) and check the same on a different machine where the problem doesn't occur...
0
 
GlennDeanAuthor Commented:
I don't know if this will give any clues to what's causing my problem, but here's the MFC dll information on my 3 systems:
MFC42.DLL
W98: Modified 6-17-98 Version 6.00.8168.0
W95: Modified 6-17-98 Version 6.0.8168.0
W2K: Modified 6-17-98 Version 6.0.8168.0

MFC42D.DLL
W98: Modified 4-23-99 Version 6.00.8447.0
W95: Modified 6-17-98 Version 6.0.8168.0
W2K: Modified 12-7-99 Version 6.0.8665.0

The odd thing that strikes out at me is that my W2K system has a "higher" version than my W98 system.  I'm wondering jkr that maybe IomegaWare overwrote my mfc42d.dll and replaced it with an older version??  

   Glenn
0
 
jkrCommented:
Well, the DLL of interest would be 'COMCTL32.DLL'
0
 
MetroCommented:
 I have ran into the same problem a couple of times at work on co-workers computers.  I also found that the problem could be:
   1.  a windows 98 dll file was corrupted.
   2.  sometimes I think there is a bug in Visual C++ ver 6
   3.  a computer virus
   4.  worse of all a harddrive falure.

   The 1 and 4 problems were the case with the experences I had.   I did solve the first one by installing windows on top of windows.  I know there are many people that say that this solution is un-wise but I found it does help, and I have done 2 successful reinstalls without any problems.

That is my only suggestion.  Hope it helps.

Metro
0
 
GlennDeanAuthor Commented:
Thanxs Metro for the info.  Given that everyone has mentioned something about DLLs, I think my best shot is to 1.  Backup all my programs
2.  Uninstall VC++ 6.0
3.  Re-install VC++ 6.0
Then see if I have the same problems again.  
  Unfortunately, I won't be able to do this until tomorrow night so I do apologize to everyone that I won't be able to give quicker feedback.  

   Glenn
0
 
PacmanCommented:
Glenn,

I had a similar problem.
Does this always happen or only sometimes?

I ask because my problem had to do with VC debugger and ASSERTs ...
0
 
DanRollinsCommented:
Another avenue of information is to run Spy++ to see which message causes the problem.

>>move the mouse into the menu part of the control bar

When you say that, I think you mean it is "when the mouse is over a button in the toolbar".  Am I right?  If so, the problem may also be related to system-wide tooltip handling -- which has cause me problems in the past.  

One way to test this theory would be to try using
   EnableTooltips( FALSE )
on the toolbar and the mainframe, etc.  

I don't have a suggestion on how to fix such a hypothetical tooltip problem, but reinstalling Windows would probably do it.  Note that the system-wide tooltip handler is part of COMCTL32.DLL and if it is corrupt or out of sync, then replacing it with a good copy could fix the problem.

-- Dan
0
 
migelCommented:
Hi!
can you send your test project?
my Email is migel.geo@yahoo.com
0
 
PacmanCommented:
> When you say that, I think you mean it is "when the mouse is over a button in the toolbar".  Am I right?
> If so, the problem may also be related to system-wide tooltip handling -- which has cause me problems
in the past

That's exactly the problem that I've had on my Win98 system.
I found out that it happens when an ASSERT occurs (MFC-ASSERT-Macro) and I terminate the application directly from the assert-dialog. In this case the whole windows system gets instable. When I move the mouse over quick launch bar, for example, then the explorer crashes.

I can prevent this by jumping into Debugger (from ASSERT-dialog) and terminating the application with the debugger.

0
 
jkrCommented:
>>Another avenue of information is to run Spy++ to see
>>which message causes the problem.

Well, as the 1st parameter in

CWnd::WindowProc(unsigned int 512, unsigned int 0, long 65623) line 1586 + 26 bytes

is 512, it's WM_MOUSEMOVE :o)
0
 
GlennDeanAuthor Commented:
Migel:  The problem occurs even on a default SDI app, so I haven't even added one line of code and C0000005 occurs, so I don't think sending you the app will help since you would also need all the DLLs that a default SDI is using.  

Dan: You're right.  I just ran several more tests.  If I move the mouse over the menu items the exception doesn't occur.  As soon as I move the mouse over a button then the exception occurs.  I added the one line of code EnableTooltips(FALSE) to the mainframe class, and the same thing occurs.  

jkr: I'm gonna look at my 3 versions of 'COMCTL32.DLL' on my 3 systems and install the lastest.

I do apologize to everyone - I have to zip off to work so I will not be able to respond to comments until I get back 12 hours later :-(

  Glenn
0
 
GlennDeanAuthor Commented:
Forgot to say Pacman that the problem doesn't always occur.  After I reboot my system and run an SDI app, about after the 2nd or 3rd time I move the mouse over a button the exception occurs (so I basically get a couple of successful attempts after reboot).  From that point on, it happens 100% of the time.  As you had mentioned, my system becomes unstable in that Windows Explorer's becomes unuseable (I get "This program has performed an illegal operation and will be shut down.").  In addition, several times even W98 won't shut down completely and I have to "pull the plug" to shut things down.  

  Glenn
0
 
migelCommented:
Hi!
can you test it on pure 98 machine (only OS and your program???)
0
 
GlennDeanAuthor Commented:
Thanxs everyone!!!!!!!!!!

   Glenn
0
 
GlennDeanAuthor Commented:
I forgot to say how the problem was hopefully solved.  Based on jkr's suggestion that comctl32.dll was the one to consider, I copied the comctl32.dll file from several W98 computers.  I then, without Windows running, copied the DLL into the Windows\System folder (I couldn't have Windows running cause it wouldn't allow the copy - makes sense).  The first one I tried had a version of 5.81.  Upon installing I could only boot to DOS.  I tried a second one with version 5.80 and could boot to W98.
   Ran 3 or 4 programs that the exception occurrred on and, with the new DLL things are working normally.  
   I really feel I lucked out, because I could easily see the case none of the other W98 computers had the right version.  
0

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 8
  • 4
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now