I have an image processing C program which uses OpenCV library. I was developing this with Visual Studio 2008 until this happened. So I moved the whole project to netbeans(6.9) and MinGW.
I have configured netbeans to use OpenCV libraries as guided in this blog.
But when I run the program it gives this error " The application failed to initialize properly (0xc0150002) "
I don't think this happens when trying to read any image files from the hard disk. It gives the error without even executing 1st line in the main method.
The only change I made to the code is this.
static __inline void release_mem( CvPoint2D64f*, CvPoint2D64f*, static struct feature** );
this gave me error : storage class specified for parameter 'type name'
so I changed the code to (Trial and error rather than any logic)
static __inline void release_mem( CvPoint2D64f*, CvPoint2D64f*, struct feature** );
It is a side-by-side configuration problem. Your program contains a manifest that states what DLL it needs from the SxS cache. And Windows can't find it. Start by looking at the Windows event log, it will tell you what DLL couldn't be found.
This is more typically a VS2008 problem, its DLL version of the CRT libraries are stored in the side-by-side cache. Like msvcrt90.dll. Maybe you didn't quite manage to get the code converted to your new build environment. Which is odd, embedding the manifest is an explicit build step. Do check that you don't have a .manifest file in your build directory.
This hoopla got retired in VS2010 btw. VS2010 Express could be your 3rd attempt.
Related
detailed message box texti made a winform application on my pc and it runs fine. but when I tried to run it on another PC by copying the exe file and other dll files there , the application failed to run and all of a sudden it shows a dialog box to close the aplication.
please refer to screenshot of error.
enter image description here
Like bassfader said: One possible explanation is that your application is handling files during startup. In that case: integrate more extensive exception handling for those parts. Potentially with logging, to locate the problem
In my experience this however is more often a case of missing some kind of dependency.
Double check .NET runtimes. Lookup the target .net version in Visual Studio and run the installer on the target machine.
Investigate if your app uses any assemblies that are not part of the .NET framework. Sometimes these are not copied to the bin directory if they are in the GAC (ensure the flag "Copy Local" is set to "Always" in Visual Studio)
Ensure you have copied the whole bin folder
Check compiler output to see if you've got Platform mismatches. IIRC this can sometimes work fine on a dev machine but cause problems when Visual Studio is missing or you get to a different OS.
A while ago i wrote a C++ CLI Windows Form app, which compiled fine in Visual Studio 2013. Now i wanted to recompile it in Visual Studio 2015 Update 1 but i'm facing a problem, and after hours of tests i figured out the culprit is afxwin.h.
TL;DR - Is there any way i can use stdafx.h (so afxwin.h and all other imports coming with it) in a Windows Form app compiled with Visual Studio 2015 without having the app crash upon start?
Here's how to reproduce the same issues i'm facing in my app.
Since Windows Form is no longer available as project template in VS2015, i created a CLR Empty Project called Test
Ctrl-Shift-A to add a UI > Windows Form called MyForm
In MyForm.cpp i added this:
#include "MyForm.h"
using namespace System;
using namespace System::Windows::Forms;
[STAThread]
int main(cli::array<System::String^>^ args)
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Test::MyForm form;
Application::Run(%form);
}
Under Configuration Properties > Linker > Advanced i set Entry Point to main
Under Configuration Properties > Linker > System i set SubSystem to Windows (/SUBSYSTEM/WINDOWS)
COMPILE (DEBUG CONFIGURATION): compiles with no errors/warnings
RUN: runs without any problem.
Now lets try adding afxwin.h to MyForm.cpp:
#include <afxwin.h>
Under Configuration Properties > General i set Use of MFC to Use MFC in a shared DLL
COMPILE (DEBUG CONFIGURATION): compiles with no errors/warnings
RUN: the app wont even start, it just shows Debug Assertion Failed error in expression _CrtIsValidHeapPointer(block)
Now to fix this error i found that it's necessary to remove the Entry Point, so:
Under Configuration Properties > Linker > Advanced i removed Entry Point value (which i previously set to main)
COMPILE (DEBUG CONFIGURATION): compiles with no errors/warnings
RUN: the app again wont even start, it no longer shows Debug Assertion Failed but System.AccessViolationException in an unknown module and "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
These are the errors i get in my app, and i'm wondering how is it possible that simply including afxwin.h gives all these problems in VS2015 while it didnt in VS2013.
Is there anything i can do to fix it, without going back to VS2013?
The C runtime library was significantly rewritten for VS2015 by James McNellis. He's a big C++ fan, the new code he's written suffers from the chronic SIOF problem that's so common in a C++ program. The Static Initialization Order Fiasco was surely present in your VS2013 project as well but happened not to byte, the original CRT code was exposed to SIOF for many years so likely to behave better.
Excessively hard to debug in this case, the code that fails comes from a CRT source code file that is not included in the install named thread_safe_statics.cpp. Not 100% sure what it does given that there's no source code to look at but the name of the file leaves little to the imagination.
MFC has static state that needs to be initialized before it is usable. In particular, the program must have a static CWinApp variable that is initialized at Just the Right Time. That requires the entrypoint to be WinMain(), implemented in MFC, and an explicit declaration of a CWinApp instance in your source code. Like this:
[STAThread]
int main(cli::array<System::String^>^ args)
{
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew Test::MyForm);
}
class MyMfcApp : public CWinApp {
public:
virtual int Run() override {
return main(__nullptr);
}
} MyApp;
Reset the linker's EntryPoint setting back to its default (blank) so the CRT is initialized first and MFC's WinMain function runs next. And beware I took a shortcut, you get no args. And I fixed a bug in your main() function, it used stack semantics incorrectly.
This hack gets your program running again. Whether it is actually correct is rather doubtful. This suffers from the "Who is the Boss" syndrome that's associated with big frameworks. Don't depend on any MFC window to work correctly since it is Winforms that is dispatching messages. But you should have had that problem in VS2013 as well. "Don't do it" is the only solid advice.
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
I'm a rookie at C in general and VS 2013 also. I am trying to use some C code provided by a vendor in VS 2013 express. It compiles and runs without problem using the command line compiler but I would like to use the IDE.
I started a new project, C++ for console app, and I have pasted the code into the IDE and saved it as xyy.c so that it builds successfully. I thought it would be nice to have it in a GUI, so I duplicated the effort with a Win32 app project. It also builds.
The program's job is to connect to a PCI card that has Plx chip as an interface and program an FPGA. The Win32 program succeeds, even though I can't see any of the info printed by the program. The console program fails and I think it is because it fails to find the driver for the Plx chip. I thought I would get a clue by single stepping through the Win32 program to see which driver was supposed to be found.
However, after the first pass through a while loop, I get a pop up that says "Source Not Found" and "stack.cpp not found". Google wasn't any help to me.
I be grateful for any suggestions.
You might have "Enable .NET Framework source stepping" enabled (see http://msdn.microsoft.com/en-us/library/cc667410.aspx). So when you are at Stack... and trying to step into, it will actually try, but you don't have the sources for that. There is also a new experience for using the .NET framework reference source that was announced recently: http://blogs.msdn.com/b/dotnet/archive/2014/02/24/a-new-look-for-net-reference-source.aspx
I faced the same problem. I advise at the moment of receiving the information "stack.cpp not found" to look at the stack trace and check if there is something like this: "RTC".
If there is, you need to change the flag along the path (for example, set the Default or a more convenient configuration for you):
Project Properties -> C/C++ -> Code Generation -> Basic Runtime Checks
More details: https://learn.microsoft.com/en-us/cpp/build/reference/rtc-run-time-error-checks?view=msvc-160
I'm attempting to use Dotfuscator 4.7.1000 to obfuscate a Silverlight library that is strongly named. When I attempt to do so, I get the following error message:
External type not found
System.Data.Services.Client.LoadCompletedEventArgs,System.Data.Services.Client,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
I have tried adding this assembly to the GAC, and have tried adding user defined assembly load paths to the configuration to locations where this assembly is located to no avail.
I then tried adding System.Data.Services.Client to the input assemblies and ran it again. This time it gets further, but ultimately I get:
Warning: Password protected Strong Name files are not supported
sn returned 1.
It appears as though it is attempting to run sn.exe on System.Data.Services.Client.dll with my local key. I've tried excluding this assembly from any obfuscation tasks, but it continues to do so.
Is there something I'm missing when trying to obfuscate this library? Is there some other way to directly point it to the DLL it can't seem to find that I don't know about? Or can I include the DLL in the project without it trying to obfuscate the Silverlight library?
And for the moment, please no suggestions on alternate obfuscators. My company has a license for Dotfuscator and I'd like to get this running using that. Thanks!
Somehow I must have been screwing up my user defined assembly load paths. As soon as I re-added the path to the Silverlight 4.0 client DLLs everything worked without having to reference System.Data.Services.Client.