C++ Builder XE7: Using TChart in packages - c++

I am confronted with a weird situation and I couldn't find any informations about this yet.
I have postet this issue allready on the new Embarcadero community forum but I'm not very hopeful that I will get an answer there... So I decided to create a new account here.
http://community.embarcadero.com/index.php/forum/tools/336-c-builder-xe7-and-teechart-standard)
I use the TChart component which is shiped with the IDE of XE7 (like in older versions). When I
use it in a package (.dll or .bpl) I get an access violation when I dynamically load, unload, and reload (reloading is the problem) the package wich contains a form with a chart in it. I looked at the loaded packages with a process monitoring tool and everything seems to be allright. The Tee9210.bpl is loaded successfully. When compiling the projects with /XE6 this error doesn't occur.
I could reproduce this on a second environement so I don't think its an issue of my installation/pc.
Can anybody reproduce this? I could provide a test project if needed.
Thank you in advance.
Kerem
Edit:
Access Violation when loading the bpl the second time:
Exception class: $C0000005
Message: 'access violation at 0xeeffeeff: access of address 0xeeffeeff'
I noticed that when I try to load the bpl again after this message I get a different exception:
Exception class: $C0000005
Message: 'access violation at 0x503230cf: read of address 0x00000000'

Sorry for posting the same question on two pages, but I wasn't sure if the new embarcadero
forum is popular enough to expect an answer from there.
But fortunately Yeray from Steema is active there, too. And I hope the solution could be read on the following link soon.
http://community.embarcadero.com/index.php/forum/tools/336-c-builder-xe7-and-teechart-standard

Related

This application has requested the runtime to terminate it in an unusual way QT C++

I am developing a Fifteen Puzzle Game in QT C++. Game works sometimes fine and sometimes crashed during run. I don't know the problem. I looked into different forums and found different suggestions. Some say this error is due to missing dll etc.
A window appears with Error is below
Microsoft Visual C++ Runtime Library
This application has requested the runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I solved the problem: Actually I was accessing a vector location which was not available. assert() helped me to troubleshoot. Thanks #DNT

No symbols are loaded for any call stack frame. The source code cannot be displayed

please can anybody help me? I'm suffering - every time I debug my c++ (opencv) code, I have an exception and then the following msg:
No symbols are loaded for any call stack frame. The source code cannot be displayed.
What's the matter, and how can I solve it? my colleagues have executed the same code but had no errors or exceptions.
I am running Windows 7 32 bit and Visual Studio 2005, opencv 2.2.0
Although the OP's issue has been solved, there is another possibility for this error that I have come across (might help someone else).
You can check under Debug->Exceptions; if any of the exceptions in this window are checked, it may show that popup if you come across a First Chance Exception. None of these need to be checked to simply debug your code, but are helpful if you're trying to track down a particular exception.
My problem has been solved... It was a problem with an image path.

Intraweb class not found at runtime

I've beenworking with the IntraWeb framework on Borland C++Builder. Sometimes it happens that an application crashes because of a strange uncaught exception:
An unhandled application error has occured within My IntraWeb Application.
...
Error message raised by the application: Class TIWTimer not found
This happens when a new session is started. For example, by entering the address in a browser.
Also, the message appears in the classic IntraWeb error web page
The class that cannot be found is either TIWTimer or TIWButton but I think this is irrelevant.
The problem seems to occur randomly and sometimes goes away with a rebuild, but other times it will go away by rewriting the code or starting from a new project.
So, the question is, how come the link error is not found at link-time?
Why does it occur at all, since those classes belong to the standard IW library?
Has anyone had the same issue?
How can it be solved?
Use Intraweb XII in C++Builder XE2, it has good improvement and bug fixes.
in this version you can assign urls to forms, for example:
myhost/login.htm or myhost/login.aspx
for more information see this

C++ DX11 application only runs in Visual Studio IDE

Alright, I presented this question on the MSDN forums but have yet to receive any kind of response so I figured I'd give StackOverflow a try.
I'm currently developing a DirectX application using VS2008 on Win7. I recently experienced a nasty memory corruption bug with a memory allocation class that grabbed byte aligned memory. During this bug I could still run the debug and release executables however it would crash due the instructions getting corrupted or whatever, but it would still execute for a bit until the crash.
I then stripped out the entire memory allocation class. The application runs perfectly in the IDE (release and debug builds) but I can't run any of the executables at all. They immediately crash with a non-responding/stop working error. And I don't think it is my environment because I get the same issue on another computer that wasn't having problems before either.
Dependency walker gives a "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module." error and indicates that GPSVC.dll and IESHIMS.DLL can't be found. I've read that this can be misleading and just indicates a potential problem somewhere. And Dependency walker wasn't giving me this error the day before.
I haven't tinkered with any of the configuration or project settings or added new code. Any idea of what could be causing this behavior?
Also another note, I installed the Windows 7.1 sdk the same day. Think this could be some kind of compiler related bug?
Just in case some useful information pops up on the MSDN post, here is the link
http://social.msdn.microsoft.com/Forums/en-IE/vsdebug/thread/f692b394-8af2-4453-991c-aa6a443a9019
Thanks!
Edit -
Here is the last couple lines of Dependency Walker's profiling output
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAE4F and returned 0x77B59D65.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "EncodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF60 and returned 0x77B60FDB.
GetProcAddress(0x76CD0000 [c:\windows\syswow64\KERNEL32.DLL], "DecodePointer") called from "c:\windows\syswow64\NVWGF2UM.DLL" at address 0x6D8BAF70 and returned 0x77B59D65.
Second chance exception 0xC0000005 (Access Violation) occurred in "c:\users\joel\desktop\DXAPP.EXE" at address 0x0110152E.
Exited "c:\users\joel\desktop\DXAPP.EXE" (process 0x27D8) with code 255 (0xFF).
Is this referring to a DLL grabbing a null pointer or to my actual instructions? Going to read up on how to use WinDbg real quick and I'll post it's output if this doesn't shed any immediate light on the issue.
Edit 2 -
Simply running the application and hitting debug to bring up Visual Studio consistently brought me to where I'm compiling my shaders. I'm assuming at the moment that the root of the problem lies around this. However, I still don't understand the change of behavior during execution between using the IDE and not.
Solution! -
I was so thrown off by the previous memory corruption bug that I didn't realize my shaders weren't in a local directory to the executables. This in turn was generating a null pointer that wasn't handled properly after calling D3DX11CompileFromFile().
Shoot, sorry I meant to post this as a comment...
I can only suggest more diagnostic attempts.
One would be to profile the app from within Depends, this will also show dynamic DLL loads and might show something new. Also it captures the debug output. It may behave differently than launching in the debugger itself and provide a clue. You don't mention actually profiling so I thought I'd suggest it in case you hadn't. Also, pay very close attention to the paths for the DLL's loaded - you might be surprised at a DLL loading from a location other than you intended.
Another suggestion is to try at attach to the stopped app after the crash (before dismissing the error dialog). See if you can get a stack trace or anything out of it.
Finally try attaching (or even launching from) WindDbg rather than the IDE. Like the Depends profile, the difference in debugger behavior and how it hooks the app may allow the crash to happen, while providing the clues you need.
Good Luck!

Getting faulting module OLEACC.dll, version 4.2.5406.0 error in Event viewer application log?

My application crashes with an error saying "Demo Application pk/si component has stopped working". The systems Event Viewer log shows an error with the following details.
"Faulting application Demo.exe, version 1.0.0.1, faulting module OLEACC.dll,version 4.2.5406.0, time stamp 0x4549bd93,exception code 0xc0000005,fault offset 0x00004062,process id 0x154c,application start time 0x01c9ee94aab4c550"
I am using Windows Vista Home Premium edition and the application which i created was a Vc++ SDI application.
Please let me know if anyone have come across this issue and what could be the possible solution for the same.
Thanks in Advance,
It looks like good old access violation to me. It looks like you writing/reading from an invalid memory location in your application.
It's most likely a bug somewhere in your code that is passing invalid values to some Windows functions, and somewhere further down the line this results in a crash. Just because it isn't your DLL where the crash occurs doesn't mean it isn't your fault!
Although this isn't very helpful, all you can do is hook up a debugger to your program and reproduce the crash, then debug it.