Program triggers a breakpoint when run in debugger but works if run without debugger

Question

I created a dll and it is getting attached with a server application. Now the problem is, if I run the server from the command prompt then the dll will be running fine. But if I debug the server in visual studio then the server will crash because of dll. Then I debugged it thoroughly and got to know that it is crashing while assigning the memory. I checked evry possible thing, memory overwrite, memory leak, but everything seems to be fine.

Anyone encountered this type of problem before. Why is this happening? I searched on the internet also but all I am getting is " crashing in release mode and not in debug mode".

EDIT:

I am getting the following message on the window:

Windows has triggered a breakpoint in tcas.exe. This may be due to a corruption of the heap, which indicates a bug in tcas.exe or any of the DLLs it has loaded. This may also be due to the user pressing F12 while tcas.exe has focus. The output window may have more diagnostic information.

If I click on continue, then their wont be any problem.

Edit:

Sorry I forgot to mention that it is the debug build I am using and not the release build.

More information about the crash would be helpful if you want an answer, but crashing in release and not debug is often a sign of heap corruption somewhere, overwriting the end on an array or something — camelccc, May 10 '13 at 09:44
If heap corruption is happening then this should also happen when I run the application in the command prompt. I guess memory relaxation is more while debugging. — Arpit, May 10 '13 at 11:24
not necessarily - heap corruption can occur, but because there are far fewer checks in Release builds, you often don't notice. The debug build is deliberately noticing some corruption (no matter how minor) and crashing for you. Use the debugger to see what the problem is. — gbjbaanb, May 10 '13 at 11:31
@gbjbaanb: Sorry I forgot to mention that it is the debug build I am using and not the release build. — Arpit, May 10 '13 at 12:22
OK seeing that you are almost certainly overwriting the end of something, and not necessarily anywhere near the point in the code you are crashing. Once I had a problem like this and it turned out that I'd muddled the names of 2 things hundreds of lines earlier. have a look here http://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows — camelccc, May 10 '13 at 13:01
When you run your program with the debugger attached, you also automatically get the debug heap. Which tells you when you screwed up by displaying this message and invoking a breakpoint. Not getting this warning does **not** mean that the command prompt solved your bug. — Hans Passant, May 10 '13 at 13:42
Well, I get these mostly because of dangling pointers. If it's an overrun, it usually says so. Page heap won't always help you, as it introduces delays that may make some race conditions never occur. — ActiveTrayPrntrTagDataStrDrvr, May 16 '13 at 09:58

score 3 · Answer 1 · answered May 16 '13 at 09:37

After trying everything, using all the permutation-combination and spending so much amount of my time on this, forcefully, I changed the logic of the function. And now it is working, finally. But still, I am searching the answer for my original problem.

One thing I also didn't understand is that I read about the same problem, as mine, here http://www.debuginfo.com/tips/userbpntdll.html and when I enable full pageheap for my application, as mentioned in the blog, my application works fine. It doesn't get crash while debugging. And I enabled it, in first place, so that I can get a detailed information about heap corruption. I hope this blog will help others having the similar issue.

The info in such page helped me a lot! Thanks! – ebasconp May 19 '15 at 20:27 — ebasconp, May 19 '15 at 20:27

score 0 · Answer 2 · answered May 10 '13 at 16:24

Your program likely has a bug that's causing heap corruption.

When you run in the debugger, your program uses a special version of the heap designed to help find these types of bugs.

When you run from the command prompt, your program (even a debug build) doesn't get (all) the same help in finding heap corruption. Your program still has a bug, but you're just getting "lucky" that you don't notice any problem in the test run.

Read up on the debug heap and use it (in the debugger) to find and fix your bug.

score 0 · Answer 3 · answered May 10 '13 at 18:44

0

If you have pointers in your code you most likely are accesing somewhere unallocated memory using one of the pointers, so when the destructor runs, it crashes your program.

At least that is what I had when the problem was the same.

answered May 10 '13 at 18:44

Alexandru Barbarosie

2,952
3
24
46

Karim Takieddine · Answer 4 · 2016-06-23T23:38:11.080

I am obviously very late to the party but I thought I would share my experience with this issue in an attempt to shed some light.

I am currently developing a lightweight windowing library wrapping Windows API functionality.

The declaration of my top most Window class includes a pointer to the base address of an CHAR array representing both the WNDCLASSEX class name and the corresponding window's title. This string is allocated on the Heap and always copied in Window's constructor to avoid unregistering a NULL class name when a Window object is destroyed for instance. Window's destructor also calls delete[] on the CHAR buffer.

The problem first occurred when I started implemented a free-standing message processing function for use with one or more Window (or derived class) instances. The loop is as follows:

DWORD win_api::BeginQueueingMessages
(
    Window const *  windowList,
    UINT            length,
    INT             showCommandIndex
)
{
    BOOL processMessages    = TRUE;
    BOOL isFirstIteration   = TRUE;

    while (processMessages)
    {
        for (UINT i = 0; i < length; ++i)
        {
            Window  window  = windowList[i];
            HWND    handle  = window.getHandle();
            MSG     message = {};

            if (isFirstIteration)
            {
                ShowWindow(handle, showCommandIndex);
                UpdateWindow(handle);

                isFirstIteration = FALSE;
            }

            if (GetMessage(&message, handle, NULL, NULL))
            {
                TranslateMessage(&message);
                DispatchMessage(&message);
            }

            else
            {
                processMessages = FALSE;
            }
        }
    }

    return 0;
}

I have eventually identified the following line of code as the culprit:

Window window = windowList[i];

I made the mistake of invoking an automatically implemented copy constructor triggered by the use of the assignment operator. Thus the internal CHAR pointer of the left-hand side operator now points to the same location as windowList[i]'s member without allocating new heap memory.

Later, during program termination delete[] is called on an uninitialised block of memory and throws a C run time exception.

I hope this helps.

Program triggers a breakpoint when run in debugger but works if run without debugger

4 Answers4