I'm trying to profile a C++ project in Embarcadero RAD Studio 2010. To do this I wanted to use AQTime, but I'm running into a bit of a problem.
I can compile and run the application in release mode. But when I compile in debug mode, using the settings mentioned at http://smartbear.com/support/viewarticle/18053/, I get an access violation.
... faulted with message: 'access
violation at 0x062324bd: read of
address 0x62324bd'. Process stopped.
Use Step or Run to continue.
It seems to come when I load a bunch of dll's at the startup. But since it goes well in release mode I can't seem to figure out what could be the cause.
When the access violation occurs I get thrown out into assembly and that isn't one of the languages I'm fluent in ;)
EDIT : When scanning the .exe with Dependency Walker I get a message saying that the following files can't be found
CC32100MT.DLL
INET140.BPL
RTL140.BPL
VCL140.BPL
IESHIMS.DLL
Could this be the problem somehow? Are these debugspecific or is Dependency Walker not giving me correct information? The same files are said to be missing when I try a release compiled version to.
I'm running on Windows 7 x64, if that could be part of the issue. I have had problems before with the symlink-look-alike (user/AppData/Local...) that MS used for some folders. Notably when I ran an apache server and the htdocs folder actually wasn't located where the server thought it was (and where it appeared to be) :)
Have you tried disabling dynamic rtl which can be found in the C++ builder linker options pane?
Related
I'm trying to set up a Windows Server-based continuous integration server to completely build and package an Unreal Engine 4 project. The vast majority of the process works, but at the content cooking stage I keep running into the following errors:
********** COOK COMMAND STARTED **********
Running UE4Editor Cook for project C:\workspace\CEIT_ingame-native-plugins_PR-44\sampleProjects\unreal\ShooterGame26\ShooterGame.uproject
Commandlet log file is C:\Unreal426\Windows\Engine\Programs\AutomationTool\Saved\Cook-2021.07.05-13.56.23.txt
Running: C:\Unreal426\Windows\Engine\Binaries\Win64\UE4Editor-Cmd.exe C:\workspace\CEIT_ingame-native-plugins_PR-44\sampleProjects\unreal\ShooterGame26\ShooterGame.uproject -run=Cook -TargetPlatform=WindowsClient -fileopenlog -ddc=DerivedDataBackendGraph -unversioned -abslog=C:\Unreal426\Windows\Engine\Programs\AutomationTool\Saved\Cook-2021.07.05-13.56.23.txt -stdout -CrashForUAT -unattended -NoLogTimes -UTF8Output
LogInit: Display: Running engine for game: ShooterGame
LogModuleManager: Warning: ModuleManager: Unable to load module 'C:/Unreal426/Windows/Engine/Binaries/Win64/UE4Editor-OpenGLDrv.dll' because the file couldn't be loaded by the OS.
LogModuleManager: Warning: ModuleManager: Unable to load module 'C:/Unreal426/Windows/Engine/Plugins/Lumin/MagicLeap/Binaries/Win64/UE4Editor-MagicLeap.dll' because the file couldn't be loaded by the OS.
Took 14.257796s to run UE4Editor-Cmd.exe, ExitCode=1
ERROR: Cook failed.
(see C:\Users\jenkins\AppData\Roaming\Unreal Engine\AutomationTool\Logs\C+Unreal426+Windows\Log.txt for full exception trace)
AutomationTool exiting with ExitCode=25 (Error_UnknownCookFailure)
BUILD FAILED
Specifically, UE4Editor-OpenGLDrv.dll and UE4Editor-MagicLeap.dll cannot be loaded, but there's not any clear indication as to why this is, just that "the file couldn't be loaded by the OS". The log files written to disk don't tell me much more than the information above. I've verified that both DLLs are actually present on the CI server, so I suspect that there is some other sub-dependency missing.
I've tried running Dependencies on the Unreal executable and the DLLs mentioned in the logs to work out which DLLs might be missing on the server machine itself, but this takes over three hours to run to completion, so is a bit awkward and time-consuming to do repeatedly. I've followed the advice regarding missing dependencies from this page, and have gone through all of the likely DLLs that were reported as not found by the Dependencies utility (mostly DirectX/OpenGL related ones), but the build still fails and I'm running out of ideas.
Is there any easy way in Windows to work out exactly why a DLL fails to load? I seem to remember that Windows DLL loading error messages are nowhere near as informative as on Linux, but perhaps there's a tool or an easier method to work it out that I'm not familiar with.
EDIT: I've narrowed things down somewhat - if I attempt to load glu32.dll completely dynamically in a program of my own, I get the load error Could not load C:\Windows\System32\glu32.dll: The specified procedure could not be found. As this is on the load attempt, rather than attempt at looking up a function, it implies that some procedure is missing on a sub-dependency of glu32.dll, but I don't know how I'd go about identifying which one it is.
You can try to delete Engine/Intermediate and click GenerateProjectFiles.bat to regenerate the whole project if you use UE Source code to start up, see UE documentation and rebuild with Visual Studio.
If you use the UE4-Editor to start up lacking dll, just add dependency within YourProject.build.cs like a third party, see UE document.
I'm trying to use ros in cpp with Visual Studio 2012. I wrote the publisher and subscriber tutorial (http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber%28c%2B%2B%29) and first, I configure the project as says in the guide (http://wiki.ros.org/win_ros/hydro/Msvc%20SDK%20Projects).
Then i compiled an linked the publisher, but when I tried to run it, ros::init(argc,argv,"talker") throws an exception... The console says that I ROS_MASTER_URI is not defined but I've got it defined
There are 2 images here:
https://www.dropbox.com/s/o12m0l38gaxiugi/error1.png -
https://www.dropbox.com/s/ocdmf0wj6rj0962/error.png
Can anyone helps me?
Thanks in advance
So, I had the same issue, although I didn't set the ROS_MASTER_URI globally.
I managed to get around this specific issue by adding
ROS_MASTER_URI=http://localhost:11311
to the debugging environment variables (Project->Properties->Configuration Properties->Debugging->Environment).
However, after implementing the above I got an uncaught exception (Unhandled exception at 0x768bc41f in ros_demo.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0028f0e4..).
That went away when I built, compiled and ran the project in release mode (which matched my ROS SDK build).
I got the idea for the release/debug build from here:
xstring isn't an OSG specific object, so the error is elsewhere in the
3rd party dependency chain. As I know nothing about your OS and
software setup I can't speculate what this might be.
In general though this type of error could well be a linking issue -
for instance Visual Studio is hopeless at handling different libs
being built debug and release and will crash randomly.
That was fun to discover..
I set up the environment according to this tutorial:
http://opencv.willowgarage.com/wiki/VisualC%2B%2B_VS2010
However the picture they want you to use is no longer there, so I just saved the supplied screen shot with the same name as the original file.
Builds fine, Begins to run but then I get a runtime error
Here is the runtime error:
OpenCV_HelloWorld.exe - Application Error : The application was unable to start correctly (0xc0150002). Click OK to close the application.
I looked in Event Viewer and found that it also set off a another error but did not announce
Here is the unannounced error:
Activation context generation failed for "C:\OpenCV2.1\bin\cxcore210d.dll". Dependent Assembly Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.
As you can see it says to use sxstrace.exe however I don't appear to have that program. After a quick Google I read that the program was included in the Microsoft Windows Platform SDK, so I'm downloading the most relevant version (windows 7 version for c# and .net) and installing that to follow up on that, I'll post what I find as it comes.
Any help is very much appreciated
Unexpectedly the project builds and runs now. The only modifications made were removing spaces in the c++ directory and linker options from the tutorial. External changes were the completed installation of the windows platform SDK, however OpenCV has no dependencies with windows platform sdk. I am unsure how it was resolved, but it's no longer a problem.
I have a simple .exe written in C++ (built with Visual Studio 2005) that tests some hardware using a supplied API. It works fine on the Windows 7 machine I built it on, but when I copy it to another (Windows 7) machine and run it (from the command-line) I get:
The application has failed to start
because its side-by-side configuration
is incorrect. Please see the
application event log or use the
command-line sxstrace.exe tool for
more detail.
What is "side-by-side configuration"?
I ran sxstrace.exe and read the usage info. It appears I would need to instrument my exe to generate a log file for sxstrace.exe to be useful?
I imagine the problem is my exe requires DLLs that either don't exist on the other machine, or are the wrong version. How do I find out what DLLs my exe uses, and what versions it links to on my machine (where it works)? Any other advice on copying it to another machine and getting it running? Would more information help?
mfawzymkh's answer to the "application has failed to start because the side by side configauration is incorrect" question (linked to in the question spirulence linked to in his answer to this question) appears to apply to this question also. mfawzymkh writes:
You can resolve this issue by either
one of these 1- Install VC8 Debug CRT
2- Build you app as statically linked
And mfawzymkh's comment on that same answer explains how to build as statically linked:
when you build it in VS, go to
projects->settings->C/C++->Code
Generation and choose Runtime Lib
options to be /MTd instead of /MDd
I did that and the side-by-side configuration message is gone. (And after installing something else for the DLL I was using, my EXE works.)
For what it's worth, I encountered the same issue. In the Event Viewer I had an error message that read:
Activation context generation failed for "C:\\MyExe.exe".Error in manifest or policy file "C:\\MyExe.exe.Config" on line 12. Invalid Xml syntax.
Sure enough, I'd changed a connection string and left out the closing quote. Added that back in and it solved the issue.
"when you build it in VS, go to projects->settings->C/C++->Code Generation and choose Runtime Lib options to be /MTd instead of /MDd" worked for me, although I was interested in the Release version instead of the Debug version.
Microsofto says:
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
/MD
Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib.
Are you suffering from the same issue as this guy? Side-by-side assemblies, Windows 7, and Visual Studio 2005
I'm using Visual Studio 2005 Pro with SP1 under Windows XP 32 SP3 to build two native EXEs, A and B. A launches B. The following scenario occurs on my development system, which for now is also my test system.
When I link A and B against the debug version of the runtime library, A launches happily but then fails to launch B because the system's loader cannot find the debug version of the runtime library.
I have a theory about why this is so: The debugger has somehow put the debug version of the runtime library into the DLL search path in a way that doesn't propagate into A, so when the loader attempts to resolve B's imports, the debug version of the runtime library cannot be found.
What is the best way to overcome this? Finding the file which contains the debug version of the runtime library and adding its parent directory to the DLL search path seems like the most straightforward approach, but I can't help but wonder why the debugger hasn't done this for me. Perhaps it has a good reason which I should not attempt to second-guess.
If this is the right way to go, how can I avoid hard-coding the full pathname to the relevant directory?
Ideas?