在调试器中运行时，程序会触发一个断点，但是如果在没有调试器的情况下运行，则程序可以工作

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.