none
(exename) has encountered a problem and needs to close. We are sorry for the inconvenience... (VB.Net 2003)

    Question

  • Using Visual Basic .Net 2003 IDE (Editor) and am getting the above message at random times in a new project which receives "Windows Messages" from another program of which I have no source code. (It was done in "Visual C++ 6.0".)

    Running the program outside of the editor does the same thing.

    Also see that the actual error is 0x80000003 but the report that gets generated when this error occurs is very very confusing and offers no helpful hints as to what to look into to find the actual root cause of this issue. Have looked for a clear explanation to the 0x80000003 error but unable so far to find anything remotely helpful.

    Recompiled and reran the program after installing the latest Windows XP patches with the same results.

    Would like to FIX this problem as soon as possible since the program needs to be delivered very very soon.

    Any helpful hints would be greatly appreciated.


    Thursday, January 04, 2007 8:50 AM

Answers

  •  
    I have isolated this to Symantec Endpoint Protection. The SEP is intercepting the .NET framework. The SEP application is NOT reporting any threats.

    As soon as I uninstall (not just disable) SEP, my .NET applications start working again.

    When I reinstall SEP, my .NET applications stop working. Even my "Hello World" test applications fail to run.

    This took three days to isolate.
    Friday, February 06, 2009 2:40 PM

All replies

  • I'd guess one of two things. 

    One: this is ERROR_PATH_NOT_FOUND (value 3L) rather badly turned into an HRESULT by turning on the most significant bit (HRESULTs should really have more in them) - see Winerror.h.  This one is unlikely but not impossible

    Two: this is STATUS_BREAKPOINT (value 0x80000003L) - see ntstatus.h or WinNT.h.  This one seems more likely.

    If this guess is right then a breakpoint is (un)expectedly happening in your program.  There are a couple of ways that could happen.  One would be just execute an INT 3 coded in your program using assembler.  Another way would be to use some form of the ASSERT macro (or something similar) that uses INT 3 to gain attention when the assertion fails.  Yet another way would be for your program to corrupt memory so badly that it ends up executing some random or not so sequence of bytes that eventually looks like an INT 3.

    Figuring out which (if any) of these is your problem will probably require that you dig into the confusing report.  Doing so without access to the source for the Visual C++ 6.0 program could be really tricky (or impossible).   And, of course, the ASSERT or whatever might be in some underlying code called by your program and not in your program's own code.

    Thursday, January 04, 2007 10:27 AM
  • Frank,

    Thanks for the info... I'll look into it... but the program in question uses VB.Net 2003 with calls to receive the very frequent "Windows Messages" from the VC++ 6.0 executable.

    I tend to think that there is some unexpected Breakpoint occurring based on your post above.

    Perhaps even the "hooks" into the "Windows Messages" is causing something in memory to get corrupted or the sheer volume of messages being received is what is the cause of this issue.

    Problem is finding where to look and what is the actual underlying "root cause".

    I've seen some cases where the actual cause is not in the routine that reported the error but from bad data in another function or subroutine.









    Thursday, January 04, 2007 10:57 AM
  • I am getting this error when I try to run ANY of my compiled executables. I can run the applications, without issue, in Visual Studio 8, but as soon as I try to run the program by itself, I get this message. I get the SAME message even when I run applications I compiled one year ago and I know work. I can copy the executable to another machine and I do not have problems.

    This happens even on my "Hello World" program that I compiled using VC# in MSVS8 running .NET 2.0 with 3.5 SP1.

    What can I try next?
    Wednesday, February 04, 2009 2:08 AM
  •  
    I have isolated this to Symantec Endpoint Protection. The SEP is intercepting the .NET framework. The SEP application is NOT reporting any threats.

    As soon as I uninstall (not just disable) SEP, my .NET applications start working again.

    When I reinstall SEP, my .NET applications stop working. Even my "Hello World" test applications fail to run.

    This took three days to isolate.
    Friday, February 06, 2009 2:40 PM
  • Congratulations.  Nice sleuthing.  Virus scanners increasingly provide a cure that's worse than the disease.  Especially Symantecs'

    Thanks for posting back.

    Hans Passant.
    Friday, February 06, 2009 3:14 PM
    Moderator