Author Message

I have been running Win2k Pro on my machine since it came out...
I have been running VC++ 6 Pro ever since I got Win2k. Always
had some problems with the de{*filter*} up intil I installed SP5.
The problem was that damn message when I tried to debug an
application: "User breakpoint called from code at 0x77f9eea9"
The de{*filter*} goes automatically to the disassebly window. Here
is the listing from Call stack:

NTDLL! 77f9eea9()   <------------------------- arrow pointer
NTDLL! 77fcd942()
NTDLL! 77fb54c9()
NTDLL! 77fb4732()
NTDLL! 77fa6567()
NTDLL! 77fcabc7()
USER32! 77e1b38d()
USER32! 77e24749()
USER32! 77e24631()
USER32! 77e2422e()
SHELL32! 6980ff0d()
SHELL32! 6981fafc()
SHELL32! 6981fb53()
CDocManager::RegisterShellFileTypes(int 1) line 230 + 25 bytes
CWinApp::RegisterShellFileTypes(int 1) line 193
CCOSApp::InitInstance() line 98
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x0096251e, int 1) line 39 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
0x0096251e, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e992a6()

After I installed Service Pack 5 I couldn't come cross this problem, I WAS
EXTREMELY HAPPY. One day I crewed up my registry and I had to reinstall
Win2K. Fine...I installed Win2K Service Pack 1 then installed
VC++6 and directly installed SP5...for the love of GOD I'm getting that
damn "user brake" JUNK again ! It's driving me crazy...I uninstalled
VC++6, reinstalled, applied SP5 again and at the end I applied
Win2k SP1....same problem...

What's going on here ? How can I get rid off this problem ?

Please help...I don't know what the problem is...and its driving me crazy
becuse I can't debug

Peter

Wed, 15 Oct 2003 13:00:49 GMT
I've been reporting the same problem but have been unable to get any help
from MS.  I haven't yet been able to determine the cause, but I can tell you
how you can get back to debugging.

The problem appears to be in a buffer overwrite inside the system dlls.  The
reason it's being trapped inside W2K is that heap checking is much stronger
than in previous OS versions.  This expanded heap checking is only enabled
when the de{*filter*} is active.  Here's what you can do:

Run the GFLAGS utility by bringing up a command prompt and typing C:\>GFLAGS
<return>.  If this utility isn't on your machine you can find it on the
original W2K CD.  Inside GFLAGS enter the name of the program you're trying
to debug in the "Image File Name:" box (just the name with no path), then
select the "Image File Options" radio button on the left.  Finally, check
and then uncheck the "Stop on Exception" box and press OK.

You should now be able to debug.  What this does is puts an entry in the
registry telling W2K to bypass the detected heap problem for the specific
executable.

This is a bit of a pain, but it's the only way I've found to keep working.
The applications that cause this seem to run fine in every other way.

By the way, the problem isn't with the specific code you've written.  I can
duplicate exactly the same behavior with numerous simple SDK calls which are
unrelated as far as I can tell.

I hope this helps.

Drew Stoddard

Quote:
> I have been running Win2k Pro on my machine since it came out...
> I have been running VC++ 6 Pro ever since I got Win2k. Always
> had some problems with the de{*filter*} up intil I installed SP5.
> The problem was that damn message when I tried to debug an
> application: "User breakpoint called from code at 0x77f9eea9"
> The de{*filter*} goes automatically to the disassebly window. Here
> is the listing from Call stack:

> NTDLL! 77f9eea9()   <------------------------- arrow pointer
> NTDLL! 77fcd942()
> NTDLL! 77fb54c9()
> NTDLL! 77fb4732()
> NTDLL! 77fa6567()
> NTDLL! 77fcabc7()
> USER32! 77e1b38d()
> USER32! 77e24749()
> USER32! 77e24631()
> USER32! 77e2422e()
> SHELL32! 6980ff0d()
> SHELL32! 6981fafc()
> SHELL32! 6981fb53()
> CDocManager::RegisterShellFileTypes(int 1) line 230 + 25 bytes
> CWinApp::RegisterShellFileTypes(int 1) line 193
> CCOSApp::InitInstance() line 98
> AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> 0x0096251e, int 1) line 39 + 11 bytes
> WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> 0x0096251e, int 1) line 30
> WinMainCRTStartup() line 330 + 54 bytes
> KERNEL32! 77e992a6()

> After I installed Service Pack 5 I couldn't come cross this problem, I WAS
> EXTREMELY HAPPY. One day I crewed up my registry and I had to reinstall
> Win2K. Fine...I installed Win2K Service Pack 1 then installed
> VC++6 and directly installed SP5...for the love of GOD I'm getting that
> damn "user brake" JUNK again ! It's driving me crazy...I uninstalled
> VC++6, reinstalled, applied SP5 again and at the end I applied
> Win2k SP1....same problem...

> What's going on here ? How can I get rid off this problem ?

> Please help...I don't know what the problem is...and its driving me crazy
> becuse I can't debug

> Peter

Thu, 16 Oct 2003 00:51:02 GMT
Hi Drew,

Thank You very much for your help, I'm gonna try your recommendation -
I haven't seen this solution before.

The weird thing is that I once had this going with installing SP5 but now
that I had to reinstall the system and apply all the SPs I can't get it
going, it's very frustrating and I thought that Microsoft fixed this...

I believe that the problem should be with either Win2k or VC++6
because my application (MFC) worked well in the de{*filter*}
before I reinstalled the system. Now I can't debug the same application
(no code modification)...

Perhaps this could be a system dll  problem ?

Thanks again...

Peter

PS: I bet we are not the only ones having this problem...

Quote:
> I've been reporting the same problem but have been unable to get any help
> from MS.  I haven't yet been able to determine the cause, but I can tell
you
> how you can get back to debugging.

> The problem appears to be in a buffer overwrite inside the system dlls.
The
> reason it's being trapped inside W2K is that heap checking is much
stronger
> than in previous OS versions.  This expanded heap checking is only enabled
> when the de{*filter*} is active.  Here's what you can do:

> Run the GFLAGS utility by bringing up a command prompt and typing
C:\>GFLAGS
> <return>.  If this utility isn't on your machine you can find it on the
> original W2K CD.  Inside GFLAGS enter the name of the program you're
trying
> to debug in the "Image File Name:" box (just the name with no path), then
> select the "Image File Options" radio button on the left.  Finally, check
> and then uncheck the "Stop on Exception" box and press OK.

> You should now be able to debug.  What this does is puts an entry in the
> registry telling W2K to bypass the detected heap problem for the specific
> executable.

> This is a bit of a pain, but it's the only way I've found to keep working.
> The applications that cause this seem to run fine in every other way.

> By the way, the problem isn't with the specific code you've written.  I
can
> duplicate exactly the same behavior with numerous simple SDK calls which
are
> unrelated as far as I can tell.

> I hope this helps.

> Drew Stoddard

> > I have been running Win2k Pro on my machine since it came out...
> > I have been running VC++ 6 Pro ever since I got Win2k. Always
> > had some problems with the de{*filter*} up intil I installed SP5.
> > The problem was that damn message when I tried to debug an
> > application: "User breakpoint called from code at 0x77f9eea9"
> > The de{*filter*} goes automatically to the disassebly window. Here
> > is the listing from Call stack:

> > NTDLL! 77f9eea9()   <------------------------- arrow pointer
> > NTDLL! 77fcd942()
> > NTDLL! 77fb54c9()
> > NTDLL! 77fb4732()
> > NTDLL! 77fa6567()
> > NTDLL! 77fcabc7()
> > USER32! 77e1b38d()
> > USER32! 77e24749()
> > USER32! 77e24631()
> > USER32! 77e2422e()
> > SHELL32! 6980ff0d()
> > SHELL32! 6981fafc()
> > SHELL32! 6981fb53()
> > CDocManager::RegisterShellFileTypes(int 1) line 230 + 25 bytes
> > CWinApp::RegisterShellFileTypes(int 1) line 193
> > CCOSApp::InitInstance() line 98
> > AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> > 0x0096251e, int 1) line 39 + 11 bytes
> > WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> > 0x0096251e, int 1) line 30
> > WinMainCRTStartup() line 330 + 54 bytes
> > KERNEL32! 77e992a6()

> > After I installed Service Pack 5 I couldn't come cross this problem, I
WAS
> > EXTREMELY HAPPY. One day I crewed up my registry and I had to reinstall
> > Win2K. Fine...I installed Win2K Service Pack 1 then installed
> > VC++6 and directly installed SP5...for the love of GOD I'm getting that
> > damn "user brake" JUNK again ! It's driving me crazy...I uninstalled
> > VC++6, reinstalled, applied SP5 again and at the end I applied
> > Win2k SP1....same problem...

> > What's going on here ? How can I get rid off this problem ?

> > Please help...I don't know what the problem is...and its driving me
crazy
> > becuse I can't debug

> > Peter

Thu, 16 Oct 2003 01:35:30 GMT
Hi Drew,

I did as you said but it doesn't help for me...here is what I did (to make
sure
I followed your steps correctly:

Run gflags.exe

1) In the "image file name" I typed: "e:\cos\debug\cos.exe"

2) clicked on "Image File Option" radio button

3) Checked and unchecked "Stop On execution" check box

4) clicked "OK" button

5) Loaded VC++6 try debugging my application

Result: Same error problem...

Now what sir ? :)

Peter

Quote:
> I've been reporting the same problem but have been unable to get any help
> from MS.  I haven't yet been able to determine the cause, but I can tell
you
> how you can get back to debugging.

> The problem appears to be in a buffer overwrite inside the system dlls.
The
> reason it's being trapped inside W2K is that heap checking is much
stronger
> than in previous OS versions.  This expanded heap checking is only enabled
> when the de{*filter*} is active.  Here's what you can do:

> Run the GFLAGS utility by bringing up a command prompt and typing
C:\>GFLAGS
> <return>.  If this utility isn't on your machine you can find it on the
> original W2K CD.  Inside GFLAGS enter the name of the program you're
trying
> to debug in the "Image File Name:" box (just the name with no path), then
> select the "Image File Options" radio button on the left.  Finally, check
> and then uncheck the "Stop on Exception" box and press OK.

> You should now be able to debug.  What this does is puts an entry in the
> registry telling W2K to bypass the detected heap problem for the specific
> executable.

> This is a bit of a pain, but it's the only way I've found to keep working.
> The applications that cause this seem to run fine in every other way.

> By the way, the problem isn't with the specific code you've written.  I
can
> duplicate exactly the same behavior with numerous simple SDK calls which
are
> unrelated as far as I can tell.

> I hope this helps.

> Drew Stoddard

> > I have been running Win2k Pro on my machine since it came out...
> > I have been running VC++ 6 Pro ever since I got Win2k. Always
> > had some problems with the de{*filter*} up intil I installed SP5.
> > The problem was that damn message when I tried to debug an
> > application: "User breakpoint called from code at 0x77f9eea9"
> > The de{*filter*} goes automatically to the disassebly window. Here
> > is the listing from Call stack:

> > NTDLL! 77f9eea9()   <------------------------- arrow pointer
> > NTDLL! 77fcd942()
> > NTDLL! 77fb54c9()
> > NTDLL! 77fb4732()
> > NTDLL! 77fa6567()
> > NTDLL! 77fcabc7()
> > USER32! 77e1b38d()
> > USER32! 77e24749()
> > USER32! 77e24631()
> > USER32! 77e2422e()
> > SHELL32! 6980ff0d()
> > SHELL32! 6981fafc()
> > SHELL32! 6981fb53()
> > CDocManager::RegisterShellFileTypes(int 1) line 230 + 25 bytes
> > CWinApp::RegisterShellFileTypes(int 1) line 193
> > CCOSApp::InitInstance() line 98
> > AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> > 0x0096251e, int 1) line 39 + 11 bytes
> > WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> > 0x0096251e, int 1) line 30
> > WinMainCRTStartup() line 330 + 54 bytes
> > KERNEL32! 77e992a6()

> > After I installed Service Pack 5 I couldn't come cross this problem, I
WAS
> > EXTREMELY HAPPY. One day I crewed up my registry and I had to reinstall
> > Win2K. Fine...I installed Win2K Service Pack 1 then installed
> > VC++6 and directly installed SP5...for the love of GOD I'm getting that
> > damn "user brake" JUNK again ! It's driving me crazy...I uninstalled
> > VC++6, reinstalled, applied SP5 again and at the end I applied
> > Win2k SP1....same problem...

> > What's going on here ? How can I get rid off this problem ?

> > Please help...I don't know what the problem is...and its driving me
crazy
> > becuse I can't debug

> > Peter

Thu, 16 Oct 2003 02:27:24 GMT
Peter,

You must enter the "image file name" without the path.  Just enter it as
"cos.exe".

To check and make sure the entry is right after you run GFLAGS go to this
key in the registry:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File
Execution Options

(Be careful of the line wrap - the above key is all one line).

Under that key you should see a key value of "cos.exe".  Under the "cos.exe"
key should be a key "GlobalFlag" of type REG_SZ with a value of zero.

Then restart VC++ and you should be able to debug.  This always works for
me.

Let me know if this doesn't work and we'll try again.

-Drew

Quote:
> Hi Drew,

> I did as you said but it doesn't help for me...here is what I did (to make
> sure
> I followed your steps correctly:

> Run gflags.exe

> 1) In the "image file name" I typed: "e:\cos\debug\cos.exe"

> 2) clicked on "Image File Option" radio button

> 3) Checked and unchecked "Stop On execution" check box

> 4) clicked "OK" button

> 5) Loaded VC++6 try debugging my application

> Result: Same error problem...

> Now what sir ? :)

> Peter

> > I've been reporting the same problem but have been unable to get any
help
> > from MS.  I haven't yet been able to determine the cause, but I can tell
> you
> > how you can get back to debugging.

> > The problem appears to be in a buffer overwrite inside the system dlls.
> The
> > reason it's being trapped inside W2K is that heap checking is much
> stronger
> > than in previous OS versions.  This expanded heap checking is only
enabled
> > when the de{*filter*} is active.  Here's what you can do:

> > Run the GFLAGS utility by bringing up a command prompt and typing
> C:\>GFLAGS
> > <return>.  If this utility isn't on your machine you can find it on the
> > original W2K CD.  Inside GFLAGS enter the name of the program you're
> trying
> > to debug in the "Image File Name:" box (just the name with no path),
then
> > select the "Image File Options" radio button on the left.  Finally,
check
> > and then uncheck the "Stop on Exception" box and press OK.

> > You should now be able to debug.  What this does is puts an entry in the
> > registry telling W2K to bypass the detected heap problem for the
specific
> > executable.

> > This is a bit of a pain, but it's the only way I've found to keep
working.
> > The applications that cause this seem to run fine in every other way.

> > By the way, the problem isn't with the specific code you've written.  I
> can
> > duplicate exactly the same behavior with numerous simple SDK calls which
> are
> > unrelated as far as I can tell.

> > I hope this helps.

> > Drew Stoddard

> > > I have been running Win2k Pro on my machine since it came out...
> > > I have been running VC++ 6 Pro ever since I got Win2k. Always
> > > had some problems with the de{*filter*} up intil I installed SP5.
> > > The problem was that damn message when I tried to debug an
> > > application: "User breakpoint called from code at 0x77f9eea9"
> > > The de{*filter*} goes automatically to the disassebly window. Here
> > > is the listing from Call stack:

> > > NTDLL! 77f9eea9()   <------------------------- arrow pointer
> > > NTDLL! 77fcd942()
> > > NTDLL! 77fb54c9()
> > > NTDLL! 77fb4732()
> > > NTDLL! 77fa6567()
> > > NTDLL! 77fcabc7()
> > > USER32! 77e1b38d()
> > > USER32! 77e24749()
> > > USER32! 77e24631()
> > > USER32! 77e2422e()
> > > SHELL32! 6980ff0d()
> > > SHELL32! 6981fafc()
> > > SHELL32! 6981fb53()
> > > CDocManager::RegisterShellFileTypes(int 1) line 230 + 25 bytes
> > > CWinApp::RegisterShellFileTypes(int 1) line 193
> > > CCOSApp::InitInstance() line 98
> > > AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> > > 0x0096251e, int 1) line 39 + 11 bytes
> > > WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> > > 0x0096251e, int 1) line 30
> > > WinMainCRTStartup() line 330 + 54 bytes
> > > KERNEL32! 77e992a6()

> > > After I installed Service Pack 5 I couldn't come cross this problem, I
> WAS
> > > EXTREMELY HAPPY. One day I crewed up my registry and I had to
reinstall
> > > Win2K. Fine...I installed Win2K Service Pack 1 then installed
> > > VC++6 and directly installed SP5...for the love of GOD I'm getting
that
> > > damn "user brake" JUNK again ! It's driving me crazy...I uninstalled
> > > VC++6, reinstalled, applied SP5 again and at the end I applied
> > > Win2k SP1....same problem...

> > > What's going on here ? How can I get rid off this problem ?

> > > Please help...I don't know what the problem is...and its driving me
> crazy
> > > becuse I can't debug

> > > Peter

Fri, 17 Oct 2003 01:04:33 GMT
Hi Drew,

I Appreciate your input in this matter, I removed the path and
the de{*filter*} works now, THANKS ! I'm really happy now...

I don't understand though why when I applied VC++ SP5 before
I didn't have problems with the de{*filter*}. Now with clean install
of my system I had the problem again even with VC++ SP5. Did you
look into this matter further ? I don't know assembler so I can't
really go digging much deep...my first understanding was that
MFC memory leaks caused this problem...but when you said
it happens in Win32 application as well...could it be the VC++6
since it wasn't designed for Win2k ?

Peter

PS: I wish Microsoft recognized this as an issue, but I guess
.NET being just around the corner M$might not care... Quote: > Peter, > You must enter the "image file name" without the path. Just enter it as > "cos.exe". > To check and make sure the entry is right after you run GFLAGS go to this > key in the registry: > \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File > Execution Options > (Be careful of the line wrap - the above key is all one line). > Under that key you should see a key value of "cos.exe". Under the "cos.exe" > key should be a key "GlobalFlag" of type REG_SZ with a value of zero. > Then restart VC++ and you should be able to debug. This always works for > me. > Let me know if this doesn't work and we'll try again. > -Drew > > Hi Drew, > > I did as you said but it doesn't help for me...here is what I did (to make > > sure > > I followed your steps correctly: > > Run gflags.exe > > 1) In the "image file name" I typed: "e:\cos\debug\cos.exe" > > 2) clicked on "Image File Option" radio button > > 3) Checked and unchecked "Stop On execution" check box > > 4) clicked "OK" button > > 5) Loaded VC++6 try debugging my application > > Result: Same error problem... > > Now what sir ? :) > > Peter > > > I've been reporting the same problem but have been unable to get any > help > > > from MS. I haven't yet been able to determine the cause, but I can tell > > you > > > how you can get back to debugging. > > > The problem appears to be in a buffer overwrite inside the system dlls. > > The > > > reason it's being trapped inside W2K is that heap checking is much > > stronger > > > than in previous OS versions. This expanded heap checking is only > enabled > > > when the de{*filter*} is active. Here's what you can do: > > > Run the GFLAGS utility by bringing up a command prompt and typing > > C:\>GFLAGS > > > <return>. If this utility isn't on your machine you can find it on the > > > original W2K CD. Inside GFLAGS enter the name of the program you're > > trying > > > to debug in the "Image File Name:" box (just the name with no path), > then > > > select the "Image File Options" radio button on the left. Finally, > check > > > and then uncheck the "Stop on Exception" box and press OK. > > > You should now be able to debug. What this does is puts an entry in the > > > registry telling W2K to bypass the detected heap problem for the > specific > > > executable. > > > This is a bit of a pain, but it's the only way I've found to keep > working. > > > The applications that cause this seem to run fine in every other way. > > > By the way, the problem isn't with the specific code you've written. I > > can > > > duplicate exactly the same behavior with numerous simple SDK calls which > > are > > > unrelated as far as I can tell. > > > I hope this helps. > > > Drew Stoddard > > > > I have been running Win2k Pro on my machine since it came out... > > > > I have been running VC++ 6 Pro ever since I got Win2k. Always > > > > had some problems with the de{*filter*} up intil I installed SP5. > > > > The problem was that damn message when I tried to debug an > > > > application: "User breakpoint called from code at 0x77f9eea9" > > > > The de{*filter*} goes automatically to the disassebly window. Here > > > > is the listing from Call stack: > > > > NTDLL! 77f9eea9() <------------------------- arrow pointer > > > > NTDLL! 77fcd942() > > > > NTDLL! 77fb54c9() > > > > NTDLL! 77fb4732() > > > > NTDLL! 77fa6567() > > > > NTDLL! 77fcabc7() > > > > USER32! 77e1b38d() > > > > USER32! 77e24749() > > > > USER32! 77e24631() > > > > USER32! 77e2422e() > > > > SHELL32! 6980ff0d() > > > > SHELL32! 6981fafc() > > > > SHELL32! 6981fb53() > > > > CDocManager::RegisterShellFileTypes(int 1) line 230 + 25 bytes > > > > CWinApp::RegisterShellFileTypes(int 1) line 193 > > > > CCOSApp::InitInstance() line 98 > > > > AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * > > > > 0x0096251e, int 1) line 39 + 11 bytes > > > > WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * > > > > 0x0096251e, int 1) line 30 > > > > WinMainCRTStartup() line 330 + 54 bytes > > > > KERNEL32! 77e992a6() > > > > After I installed Service Pack 5 I couldn't come cross this problem, I > > WAS > > > > EXTREMELY HAPPY. One day I crewed up my registry and I had to > reinstall > > > > Win2K. Fine...I installed Win2K Service Pack 1 then installed > > > > VC++6 and directly installed SP5...for the love of GOD I'm getting > that > > > > damn "user brake" JUNK again ! It's driving me crazy...I uninstalled > > > > VC++6, reinstalled, applied SP5 again and at the end I applied > > > > Win2k SP1....same problem... > > > > What's going on here ? How can I get rid off this problem ? > > > > Please help...I don't know what the problem is...and its driving me > > crazy > > > > becuse I can't debug > > > > Peter Fri, 17 Oct 2003 08:50:16 GMT Frustrated with Debugger - PLEASE Help Glad you're up an running. As to the cause, I don't think it has anything to do with either VC++6.0 or the service packs you installed. I have followed the offending code down into the assembler and it appears to me to be a 1-byte buffer overwrite inside of some function in ntdll.dll. The problem is in the Win32 heap and may have some connection to the hard disk device driver, though I'm not certain of that. My conclusion is that some combination of machine hardware combined with the expanded memory diagnostics added to Win2K in debugging mode is causing a problem that has existed for years to finally start showing up. The reason hardware is implicated is that I have 2 machines side-by-side both running identical software setups. The error is triggered on one of them consistently yet has never happened on the other. We need the folks at MS to help clear this up. Unfortunately, they don't seem very interested. You want to hear a good one? After trying to get help on this for nearly 2 weeks in vain, I posted a message to this newsgroup last Thursday. On Friday I got a call from someone who wanted me to answer a bunch of questions about how happy I was with the service I had received. MS should try putting as much effort into helping developers answer their questions as they do into measuring how good their help is. Drew Stoddard Quote: > Hi Drew, > I Appreciate your input in this matter, I removed the path and > the de{*filter*} works now, THANKS ! I'm really happy now... > I don't understand though why when I applied VC++ SP5 before > I didn't have problems with the de{*filter*}. Now with clean install > of my system I had the problem again even with VC++ SP5. Did you > look into this matter further ? I don't know assembler so I can't > really go digging much deep...my first understanding was that > MFC memory leaks caused this problem...but when you said > it happens in Win32 application as well...could it be the VC++6 > since it wasn't designed for Win2k ? > Peter > PS: I wish Microsoft recognized this as an issue, but I guess > .NET being just around the corner M$ might not care...

> > Peter,

> > You must enter the "image file name" without the path.  Just enter it as
> > "cos.exe".

> > To check and make sure the entry is right after you run GFLAGS go to
this
> > key in the registry:

> > \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image
> File
> > Execution Options

> > (Be careful of the line wrap - the above key is all one line).

> > Under that key you should see a key value of "cos.exe".  Under the
> "cos.exe"
> > key should be a key "GlobalFlag" of type REG_SZ with a value of zero.

> > Then restart VC++ and you should be able to debug.  This always works
for
> > me.

> > Let me know if this doesn't work and we'll try again.

> > -Drew

> > > Hi Drew,

> > > I did as you said but it doesn't help for me...here is what I did (to
> make
> > > sure
> > > I followed your steps correctly:

> > > Run gflags.exe

> > > 1) In the "image file name" I typed: "e:\cos\debug\cos.exe"

> > > 2) clicked on "Image File Option" radio button

> > > 3) Checked and unchecked "Stop On execution" check box

> > > 4) clicked "OK" button

> > > 5) Loaded VC++6 try debugging my application

> > > Result: Same error problem...

> > > Now what sir ? :)

> > > Peter

> > > > I've been reporting the same problem but have been unable to get any
> > help
> > > > from MS.  I haven't yet been able to determine the cause, but I can
> tell
> > > you
> > > > how you can get back to debugging.

> > > > The problem appears to be in a buffer overwrite inside the system
> dlls.
> > > The
> > > > reason it's being trapped inside W2K is that heap checking is much
> > > stronger
> > > > than in previous OS versions.  This expanded heap checking is only
> > enabled
> > > > when the de{*filter*} is active.  Here's what you can do:

> > > > Run the GFLAGS utility by bringing up a command prompt and typing
> > > C:\>GFLAGS
> > > > <return>.  If this utility isn't on your machine you can find it on
> the
> > > > original W2K CD.  Inside GFLAGS enter the name of the program you're
> > > trying
> > > > to debug in the "Image File Name:" box (just the name with no path),
> > then
> > > > select the "Image File Options" radio button on the left.  Finally,
> > check
> > > > and then uncheck the "Stop on Exception" box and press OK.

> > > > You should now be able to debug.  What this does is puts an entry in
> the
> > > > registry telling W2K to bypass the detected heap problem for the
> > specific
> > > > executable.

> > > > This is a bit of a pain, but it's the only way I've found to keep
> > working.
> > > > The applications that cause this seem to run fine in every other
way.

> > > > By the way, the problem isn't with the specific code you've written.
> I
> > > can
> > > > duplicate exactly the same behavior with numerous simple SDK calls
> which
> > > are
> > > > unrelated as far as I can tell.

> > > > I hope this helps.

> > > > Drew Stoddard

> > > > > I have been running Win2k Pro on my machine since it came out...
> > > > > I have been running VC++ 6 Pro ever since I got Win2k. Always
> > > > > had some problems with the de{*filter*} up intil I installed SP5.
> > > > > The problem was that damn message when I tried to debug an
> > > > > application: "User breakpoint called from code at 0x77f9eea9"
> > > > > The de{*filter*} goes automatically to the disassebly window. Here
> > > > > is the listing from Call stack:

> > > > > NTDLL! 77f9eea9()   <------------------------- arrow pointer
> > > > > NTDLL! 77fcd942()
> > > > > NTDLL! 77fb54c9()
> > > > > NTDLL! 77fb4732()
> > > > > NTDLL! 77fa6567()
> > > > > NTDLL! 77fcabc7()
> > > > > USER32! 77e1b38d()
> > > > > USER32! 77e24749()
> > > > > USER32! 77e24631()
> > > > > USER32! 77e2422e()
> > > > > SHELL32! 6980ff0d()
> > > > > SHELL32! 6981fafc()
> > > > > SHELL32! 6981fb53()
> > > > > CDocManager::RegisterShellFileTypes(int 1) line 230 + 25 bytes
> > > > > CWinApp::RegisterShellFileTypes(int 1) line 193
> > > > > CCOSApp::InitInstance() line 98
> > > > > AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000,
char
> *
> > > > > 0x0096251e, int 1) line 39 + 11 bytes
> > > > > WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char *
> > > > > 0x0096251e, int 1) line 30
> > > > > WinMainCRTStartup() line 330 + 54 bytes
> > > > > KERNEL32! 77e992a6()

> > > > > After I installed Service Pack 5 I couldn't come cross this
problem,
> I
> > > WAS
> > > > > EXTREMELY HAPPY. One day I crewed up my registry and I had to
> > reinstall
> > > > > Win2K. Fine...I installed Win2K Service Pack 1 then installed
> > > > > VC++6 and directly installed SP5...for the love of GOD I'm getting
> > that
> > > > > damn "user brake" JUNK again ! It's driving me crazy...I
uninstalled
> > > > > VC++6, reinstalled, applied SP5 again and at the end I applied
> > > > > Win2k SP1....same problem...

> > > > > What's going on here ? How can I get rid off this problem ?

> > > > > Please help...I don't know what the problem is...and its driving
me
> > > crazy
> > > > > becuse I can't debug

> > > > > Peter

Fri, 17 Oct 2003 23:24:26 GMT

Quote:
> Glad you're up an running.

> As to the cause, I don't think it has anything to do with either VC++6.0
or
> the service packs you installed.  I have followed the offending code down
> into the assembler and it appears to me to be a 1-byte buffer overwrite
> inside of some function in ntdll.dll.  The problem is in the Win32 heap
and
> may have some connection to the hard disk device driver, though I'm not
> certain of that.

> My conclusion is that some combination of machine hardware combined with
the
> expanded memory diagnostics added to Win2K in debugging mode is causing a
> problem that has existed for years to finally start showing up.  The
reason
> hardware is implicated is that I have 2 machines side-by-side both running
> identical software setups.  The error is triggered on one of them
> consistently yet has never happened on the other.

Interesting...thanks for your insight. Maybe Win2K SP2 will fix it...
I'm really glad that I can debug now...it was pain otherwise...

- Show quoted text -

Quote:

> We need the folks at MS to help clear this up.  Unfortunately, they don't
> seem very interested.

> You want to hear a good one?  After trying to get help on this for nearly
2
> weeks in vain, I posted a message to this newsgroup last Thursday.  On
> Friday I got a call from someone who wanted me to answer a bunch of
> questions about how happy I was with the service I had received.  MS
should
> try putting as much effort into helping developers answer their questions
as
> they do into measuring how good their help is.

> Drew Stoddard

Why am I not surprised <g>  I'm not really happy how things are going with
.NET and Windows XP....I never was against M$neither was I for it blindly but its starting to be a bit too much. That subscription BS for XP is just going too far...the new M$ president is from my point of view an idiot.

Peter

PS: Once again thank you for your time and help....

Sat, 18 Oct 2003 08:31:38 GMT

Quote:
> > My conclusion is that some combination of machine hardware combined with
> the
> > expanded memory diagnostics added to Win2K in debugging mode is causing
a
> > problem that has existed for years to finally start showing up.  The
> reason
> > hardware is implicated is that I have 2 machines side-by-side both
running
> > identical software setups.  The error is triggered on one of them
> > consistently yet has never happened on the other.

> Interesting...thanks for your insight. Maybe Win2K SP2 will fix it...
> I'm really glad that I can debug now...it was pain otherwise...

Well, I don't think it's Win2k related, as I get it on WinNT 4 SP6 as well.
It also occurs in NTDLL.DLL, for me it happens in  the LocalFree function.
As soon as I put a break point near something that causes a LocalFree (Like
NetApiBufferFree) I get the user breakpoint problem.

Jeroen-bart Engelen

Mon, 20 Oct 2003 07:51:37 GMT

Quote:
> > > My conclusion is that some combination of machine hardware combined
with
> > the
> > > expanded memory diagnostics added to Win2K in debugging mode is
causing
> a
> > > problem that has existed for years to finally start showing up.  The
> > reason
> > > hardware is implicated is that I have 2 machines side-by-side both
> running
> > > identical software setups.  The error is triggered on one of them
> > > consistently yet has never happened on the other.

> > Interesting...thanks for your insight. Maybe Win2K SP2 will fix it...
> > I'm really glad that I can debug now...it was pain otherwise...

> Well, I don't think it's Win2k related, as I get it on WinNT 4 SP6 as
well.
> It also occurs in NTDLL.DLL, for me it happens in  the LocalFree function.
> As soon as I put a break point near something that causes a LocalFree
(Like
> NetApiBufferFree) I get the user breakpoint problem.

>     Jeroen-bart Engelen

I'm a bit surprised as I have at work NT4 but with SP5 and it doesn't happen
on that machine...but then again...this issue seems to occur randomly...

Peter

Tue, 21 Oct 2003 07:21:43 GMT

 Page 1 of 1 [ 10 post ]

Relevant Pages