User defined breakpoint associated with Microsoft.Jet.OLEDB (possibly)

I have the following problem:

Visual Studio 6.0, Service Pack 6, C++, Windows XP
Software is using “Microsoft.Jet.OLEDB.4.0”

After a view hours of operation in debugger, the software stops with the message box “User defined breakpoint”.

Message in output window is:

HEAP[App.exe]: HEAP: Free Heap block 5cbf760 modified at 5cd2f4c after it was freed

Output in callstack window:

NTDLL! 7c911230()
NTDLL! 7c959b79()
NTDLL! 7c9369a9()
NTDLL! 7c97e062()
NTDLL! 7c95a5d0()
NTDLL! 7c9368ad()
MSJET40! 1b005262()
MSJET40! 1b04af35()
MSJET40! 1b01a6f2()

Memory and 5cbf760:

05CBF760  14 2D 15 24 AC 14 18 01 78 01 34 05 48 AE C9 05 EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE FE EE and so on ...

Memory at 5cd2f4c:


Here is this FC. This is causing the problem.

I have no idea, how this FC was written to this address. But before allocating memory the debugger checks the memory for the sequence of FE EE. FC is not expected and so the debugger stops the software.

Has anybody an explanation what FC in terms of memory means?

I also can not explain the callstack. This thread is not the main thread and no thread I did start (they all have names). The software is doing inter process communication to a service by COM. Maybe it is a callback from this service?

Thanks for some good advice.

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mahesh1402IT ProfessionalCommented:
>>After a view hours of operation in debugger, the software stops with the message box “User defined breakpoint”.

The point in time when the Heap corruption is detected can be far from the time when the corruption has happened.

I would recomend to get an OS-level debugger with tools and commands that understand the heap. <==

Enable Full PageHeap on the application. Run your app under debugger, till it hits an AV or some breakpoints
You may attempt to run` !heap -p -a <bad-address>' to get information on your block.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
    If u give us some details like what are the functions that are invoked before the actual error message is thrown or is the error message pops up after doing certains operations or something like that, then we may get some ideas regarding it.
Since you are running under the debugger, the StackTrace window should tell you which function your own program was calling at the time that the memory corruption was destroyed.  However, that rarely unearths the part of the code that actually caused the corrption to occur.  

This is a particularly difficult issue becasue it is multi-threaded and it takes "several hours" for the bug to occur.  If you can find any way to make the bug occur more rapidly, then you will have a better chance of discovering the underlying problem.

Not a concrete solutiuon, but a suggestion: It appears that the MSJET40 DLL was running at the time of the error.  That would indicate that some database-related problem occurred.  Perhaps you are keeping connections open for a long period or (most likely) there is an issue related to multiple threads trying to access the same db connection... something only those lines.

Finally, the error message indicates that something wrote to a memory location that had already been freeded.  That is symptomatic of use of a pointer that had become invalid.  One standard "safey habit" I use is as soon as a delete an allocation, I set the value of the pointer variable to NULL.  Then if it accidently gets resued, the debugger will very quickly notify you of it.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.