Re: 64b Windows - crashes not detected

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Joseph M. Newcomer wrote:
In reading all the responses, I find it surprising that you would get a null-pointer
dereference of a virtual method to work, ever.

But the environment of a 32-bit app on a 64-bit machine is going to be ever-so-slightly
different than the same app on a native 32-bit machine that there is the possibility that
undefined pointer problems will behave differently. But NULL pointers won't. These
differences are going to be pretty obscure; for example, 0xcccccccc is potentially a valid
address in a 32-bit app running on Win64, but it requires actually having allocated
storage at that space and having linked with /LARGEADDRESSAWARE.

Have you ever heard of ASSERT statements? If I really cared, I would have written

ASSERT(p != NULL);

at places where I had ever seen a null pointer dereference. Of course, I would never,
ever run release code until I had verified that the debug code worked.

In fact, if you compile /W4 you may see more places where there are potential problems; if
you have PreFast, it will detect potential problems as well.

You can also install a VM manager (such as the one from Microsoft, which I believe is
free) and install your 32-bit OS under a VM.
joe

On Thu, 20 Aug 2009 09:20:11 +0100, phil oakleaf <news@xxxxxxxxxxxxxxxxxxxxx> wrote:

I have recently switched to a 64bit Windows platform - we're still building a 32bit MFC Application.

I have found that some bugs in my code that would happily crash on 32bit windows (Invalid pointers) do not crash on 64bit.

This makes it very hard to know if the code has been debugged

Is there anything I can do about this other than re-install 32bit Windows


Any ideas will be really appreciated

Phil
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joe

Thanks for the reply

I do use ASSERTS and I too verify the debug code works before going over to the release.

in the example I've posted if shows NULL->doSomething() does not crash on the 64bit system but does on the 32bit.

I do know that I should not allow NULL pointers but it seems reasonable to expect the debugger to catch any that do get through. On 32bit Windows it has done this for the last 15 years for me.


Thanks again
Phil


.

Relevant Pages

  • Runtime Error 401 - Where can I find more details on this error ?????
    ... Can someone give me some pointers on where to find details on this error, ... of older laptops running Windows ME. ... running the app produces this runtime error which seems to ...
    (microsoft.public.vb.general.discussion)
  • Re: Runtime Error 401 - Where can I find more details on this error ?????
    ... However on another couple of Windows ... > Terminating the app and then restarting it seems to get around the problem ... > Thanks for any pointers, ... The error correlates to showing a non-modal window while a modal one is ...
    (microsoft.public.vb.general.discussion)
  • Large Application development ideas
    ... I am looking for some ideas or pointers for an application i am ... I have a management .net web app that is using ... Problem being, I know that services can't start windows apps, can they ...
    (microsoft.public.dotnet.general)
  • Re: Windows Update after SP2 installation
    ... that is one of the dll registration entries that was in my ... Microsoft MVP - Windows Shell/User ... > pointers, hr=80040154 ...
    (microsoft.public.windowsupdate)
  • Re: How hard is socket programming?
    ... I have used 4000 MB of space under windows many times. ... Then you are using Win64. ... I don't want the conversion cost and the cost of 64-bit ... pointers right now. ...
    (microsoft.public.vc.mfc)