user breakpoint at visual studio 6.0
Ask Question Asked 5 years, 3 months ago Modified 2 years, 11 months ago Viewed 838 timesI have been using Visual Studio 6.0, and last week my computer was upgraded from Windows 7 to Windows 10.
There was no problem in executing an application made from VS6.0, but now I am struggling to fix a problem with this message:
"user breakpoint called at 0x77badadf".
This message happens even before the starting point of the problem - main() -, and I am not able to do anything about this problem. What is strange is that it doesn't appear when I do "rebuild all" for all the projects in the solution.
Any ideas on how to solve this?
edited Nov 6, 2017 at 4:32 Joshua Briefman 3,64422 gold badges2020 silver badges3333 bronze badges asked Nov 6, 2017 at 1:15
Sungsu Kim
5722 bronze badges
- Did you ever find out what this was? I have to maintain an old project with Visual C++ 6 and even a rebuild all does not fix it. – Donovan May 2, 2019 at 18:03
- The problem here is that Microsoft are shimming MSDEV.EXE, but not fully. The old trick of renaming it to something else and manually setting compatibility settings alongside replacing TLLOC.DLL, which worked up to Windows 8.x, no longer works because they seem to now detect it via something more than just the EXE name. So VC++ 6.0 works out of the box under Windows 10 (with the TLLOC.DLL fix) but then dies with the "user breakpoint called" error. It looks like they made an effort to get it working, but never tested it beyond "it starts up OK". – Dave Oct 5, 2019 at 4:46
- 1 I duplicated this with an old hard drive, installed Win10 out of the box, installed VC6 plus SP6, and it fails to allow me to run in the debugger. But ONLY when one DLL is inside another DLL. Rather odd. I have another open post on this issue. stackoverflow.com/questions/60105658/….. Any progress on this? – SpacemanScott Feb 8, 2020 at 16:48
zebada asked on 2000/5/23
User breakpoint called from code at....???
Can anyone tell me why I get the following dialog box when running the VC++ debugger on the code at the end of this question.And how to prevent it....
"User breakpoint called from code at 0x77f7629c"
I have no breakpoints set anywhere in the code.
The stack trace is:
NTDLL! 77f7629c()
NTDLL! 77f8c4de()
NTDLL! 77f7e587()
NTDLL! 77f64f43()
MYDLL! free + 45 bytes
operator delete(void * 0x00440380) line 7 + 9 bytes
std::allocator<char>::deallocate(void * 0x00440380, unsigned int 33) line 64 + 38 bytes
std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Tidy(unsigned char 1) line 592
std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >() line 59 + 39 bytes
myClass::myMethod(std::basic_string<char,std::char_traits<char>,std::allocator<char> > {0x00440381 "ABC"}) line 6 + 8 bytes
main(int 1, char * * 0x00440eb0) line 7
MYAPP! mainCRTStartup + 180 bytes
KERNEL32! 77f1ba06()
myapp.cpp
---------
#include "mydll.h"
int
main(int argc,char *argv[])
{
myClass x;
x.myMethod("ABC");
return 0;
}
myfml.cpp
---------
#pragma warning(disable : 4251)
#ifdef _MYDLL
#define MY_DLL __declspec(dllexport)
#else
#define MY_DLL __declspec(dllimport)
#endif
#include <string>
using namespace std;
class MY_DLL myClass {
public:
void myMethod(string myString);
};
myfml.h
---------
#define _MYDLL
#include "mydll.h"
void
myClass::myMethod(string myString)
{
}
2000/5/23 A user break point occurs when the program encounters an "int 3" instruction embedded in the code and that was not placed there by the debugger. This invokes the debugger. You can do this by placing a statement line
__asm int 3;
in your code. This will always invoke the debugger, you don't have manually to set a breakpoint on this line.
The debugger is finding such a line, probably because an error is being detected.
What that error is, I can't say. But it does look like it might be havign trouble deleting memory.
The problem probably originates in MyMethod, although it is detected "lower down" If you post the code for MyMethod it might help. ASKER CERTIFIED SOLUTION
nietod
2000/5/23 This is a "form" answer
*************************************
The problem is that if the EXE and DLL use the staticly linked version of the run-time library (RTL), they each have their own seperate copies of the RTL. These copies each have thier own seperate heaps for allocating memory with the new operator. The problem is that each one does not "know" about the other. So for example, if the DLL allocates memory, the memory comes from the heap in the DLL's copy of the RTL. If a pointer to that memory is passed back to the EXE (it may be passed in a subtle way, like inside a class) and if that EXE later makes changes that require that the memory specified by the pointer be deleted, then the EXE will try to delete the memory, but will not be able to find the memory inside its heap. This is is because the memory did not come from the heap. Hence the problem.
The solution is to have the EXE and all the C++ DLLS that it uses link with the DLL version of the RTL.
Then the EXE and all the DLLS will share a single copy of the run-time library and will therefore share a single heap.
To set this in VC:
"Project" menu
"Settings..." menu item
in the dialog box that appears "C/C++" tab
"Code generation" Category
in "Use run-time library:" select one of the DLL options.
(There are two DLLoptions there, one for a debug version, one for a release version. Make sure you choose the setting that is right for the version you are creating)
Note that these settings need to be changed for EVERY version (debug. release etc) of the EXE and and DLLs that is shares memory with.
******************************
The reason this applies to you is that the string class uses dynamically allocated memory to store the string. Initially the application creates this memory but the DLL tries to delete it and runs into problems, because it was not allocated on the right heap.
Let me know if you have any questions. zebada
2000/5/23 ASKER Thanks a million Nietod :)
One last question just to clear up the "what library I shoudl link with question"...
I have a workspace called "bug" with two projects: "myapp" and "mydll"
myapp project contains: myapp.cpp
mydll project contains: mydll.h and mydll.cpp
Which combinations of libraries should I use for Debug/Release for each project: myapp and mydll?
After your post I set them to:
Debug Release
---------------------- ----------------------
myapp Debug mutithreaded DLL Mutithreaded DLL
mydll Debug mutithreaded DLL Mutithreaded DLL
Should I have it like this instead?:
Debug Release
---------------------- ----------------------
myapp Debug mutithreaded Mutithreaded
mydll Debug mutithreaded DLL Mutithreaded DLL
When would I use single threaded? (I dont intead to write
any multithreaded apps) must I always link multithreaded
for the classes that I may use like "string"?
Cheers
Paul Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it! James Murphy nietod
2000/5/23 The first options appears to be the correct one both the EXE and the DLL must use the DLL RTL.
The DLL RTL is always multi-threaded as you can see.
For this project you must use the DLL vesion, so you have to use the multi-threaded version too, though you don't need the multi-threaded features.
Actually you do need them, due to the nature of DLLs, your program might not be multi-threaded, but the DLL will potentially be used by other programs simultaneously, so it is in a sense multi-threaded.
You can use the static, single-threaded libs for a program that does not share dynamcially allocated memory and that is single-threaded.
i.e. a program composed of a EXE that doesn't relly on any DLLs that you've written.
Or maybe a DLL program that doesn't pass/return dynamically allocated memory that the client of the DLL must free, or vice versa. zebada
2000/5/23 ASKER Thanks - confirmed what I found by trial and error.
I just did a full recompile of the actual application (not the dummy app I used to pose the question) had a warning when I changed all the projects in the workspace to "Debug Multithreaded DLL"
The problem is in a third party header from BEA systems (Tuxedo) - its originally from a unix box but has been modified to compile on windows.
The warning I get is
c:\tuxedo\include\uunix.h(117) : warning C4273: 'strdup' : inconsistent dll linkage. dllexport assumed.
And the relevant header file is:
....
extern "C" {
extern char *strdup(const char *);
#if defined(__cpp_stdc)
extern int setpgid(pid_t, pid_t);
#endif
#if !defined(_TMDOWN)
extern char *tempnam(const char *, const char *);
#endif
}
....
nietod
2000/5/23 Do you have code for this 3rd party lib? If so, remove this strdup() declaration from the .h file , change the lib source to use _strdup() instead, and recompile the library to use the DLL RTL.
If not, you will just have to ignore the warning and hope for the best. Don't ever use the strdup() it declares (you can remove it from the header to prevent accidental usage and to remove the warning message.). As long as this lib never expects you to free memory you allocate (or vice versa) you will be fine. But if it does, it will fail. There's nothing that can be done about that other than recompilation to use the DLL RTL, but if you don't have the source, that is not a option. You might be able to get the producers of the LIB to do so for you. ⚡ FREE TRIAL OFFER Try out a week of full access for free. Find out why thousands trust the EE community with their toughest problems. zebada
2000/5/24 ASKER Thanks for the info,
I actually work for BEA, the company that writes the software. Although I don't have access to the code I can pass along the info and maybe they will fix it in future releases.
Thanks for your help. 标签：use,code,DLL,will,EXE,User,memory,called From： https://www.cnblogs.com/ioriwellings/p/17104753.html