A C++ app crashes (only on our develop pc's where we have also VisualStudio, in all others works fine) after few second from startup. If we run it on debug we an Kernelbase.dll Module not found exception, last call at MSO.DLL!__delayLoadHelper2(). At the moment of the crash the app already loaded all the databases it use.
Tried to update all: windows, Microsoft365, visual studio etc.
Change Provider from 12.0 to 16.0
Installed Microsoft 365 Access Runtime and Microsoft Access 2013 Runtime (with these is also impossible to use Access app)
Related
I'm using Visual Studio 2017 with a ClearCase dynamic view connected to a mapped drive.
Starting a debugger session fails with:
Unable to start program filename.exe.
Operation is not supported.
Unknown error: 0x80070057.
Using a ClearCase snapshot view, the debugging session works as expected, without error message.
Visual Studio 2013 works perfectly fine with a snapshot or dynamic view.
Any help would be appreciated.
It depends on your exact ClearCase version, as seen in this PI45450 (project issue, similar but not identical to your case)
PI45450: RUNNING AN .NET EXECUTABLE IN A DYNAMIC VIEW FAILS WITH RUNTIME ERROR SYSTEM.ARGUMENTEXCEPTION 0X80070057 (E_INVALIDARG)
Recommendation:
Running the executable by specifying its fully qualified UNC
pathname may work, such as
\\view\viewtag\vobtag\<application>.exe
In your case, with Windows:
m:\viewtag\vobtag\<application>.exe
See if the full path (M:\...\<application>.exe) works better with Visual Studio 2017.
Or try and upgrade ClearCase if possible (8.0.1.10+).
There is a new ClearCase APAR for this behavior, because it was initially reported only if the CC VS 2017 integration was installed. It actually doesn't need the integration, at least not on Windows 10 with UAC on. The APAR is PI86014, but it may not be visible yet as it's really new.
The issue is specific to Visual Studio 2017, Visual Studio 2015 will open and start the debug session fine, and the debug executables load just fine from a dynamic view.
The integration released in the technote seems to be a little buggy. Perhaps the one in 9.0.0.5 and 9.0.1.1 will behave better.
We have a mixed Java/JRuby project that uses a C++-DLL developped in Microsoft Visual Studio. Recently, the supplier of this DLL upgraded their development environment to Visual Studio 2015 professional. This required installation of the new runtime libraries (vcredist_x86.exe) on our machines (which are running on Windows 7). After we did this, everything worked as expected.
However, we also use a server (Microsoft Windows Server 2003 R2 Standard Edition Service Pack 2) to run regression tests. I installed the new runtime libraries, and the DLL is loaded. But when the program is run, we get an fopen error when the DLL tries to load a certain file. errno gives 2 (ENOENT according to errno.h). The file is present, the DLL tries to load it using a relative path. It is not the first file that is opened via fopen, and access to the other files seems to work.
I do not have access to the source and cannot debug on the server and the developers of the DLL cannot reproduce the problem.
Has anyone experienced a similar problem on Windows Server after updating to Visual Studio 2015? And if so, how did you solve it?
The supplier of the DLL probably used the default toolset v140 which is not compatible with Server 2003. If you use Server 2008 for tests I suspect you'll be fine. Or if they are able to use the v140_xp toolset I suspect you'll be fine. That option is here: Configuration Properties -> General -> Platform Toolset
I hope that all is well.
I'm trying to develop an application on Visual C++ 2010 with Chromium Embedded Framework 3. The application runs perfectly on Windows 7. However when ran on Windows XP, it crashes. The first solution that I did was to check if there are missing DLLs.
When I check the debug file, it returns these errors:
[0520/140334:ERROR:gpu_info_collector_win.cc(103)] Can't retrieve a valid WinSAT assessment.
[0520/140336:ERROR:renderer_main.cc(227)] Running without renderer sandbox
Running the application in Visual Studio 2013 solved the issue. Perhaps the sandbox is built using this version.
I created an Extension SDK which basically consists of a Windows Runtime component that I have written using C++/CX. I did this so I can make my component available to developers building Windows 8 Store apps in any language (C++, C# or JavaScript).
The SDK works fine on my local machine. I can build and run my app locally both in debug and release configurations. However when I try to remote debug my app on a remote machine, I notice that my app fails when trying to use the component from my SDK. Oddly enough, this failure happens only when my app is running in Debug mode. In release mode, everything works fine.
What am I doing wrong?
Using Visual Studio 2012
I think I figured out. I included the same binary of the C++/CX WinRT component in both Debug and Retail folders under redist folder of my Extension SDK.
As a result this binary always has a dependency on the release CRT from Visual Studio 2012.
Now when I run the release version of my app remotely, both the app binary and SDK component binary depend on release CRT. And release CRT is also found on the system since the app has a dependency on the release VCLibs package. So the release app works fine.
However when I run the debug version of my app remotely, the app depends on debug CRT from Visual Studio 2012 but the SDK component depends on the release CRT. Since the app has a dependency only on the debug VCLibs package, it find only the debug CRT at runtime. Therefore the SDK component fails to load.
The solution is to ensure that when you create your SDK, your release binary depends on release CRT and your debug binary depends on debug CRT.
For more information about how C++ Runtime works for Windows Store apps, see the following link:
http://blogs.msdn.com/b/vcblog/archive/2012/09/28/10354327.aspx
Update that it now works in Visual Studio 2013
Using Visual Studio 2013
In Visual Studio 2013 the VCLibs debug AppX package contains both the Debug and Release CRT DLLs. So, in debug configuration, the app depends on the Debug CRT and the Extension SDK binaries depend on the Release CRT. Both of the DLLs are found in the VCLibs Debug AppX package. So it works.
I have a Win32 C++ Application using a handful of third-Party DLLs that is installed at some hundred costumer machines. I recently tested the x86 Version of the installation successfully on Windows XP, Windows Vista x64, Windows 7 x86 as well as Windows Server 2008 x86. No Problems. The Installer (nullsoft) installs the redistributable files for VC 2005 and VC 2008 as both are required by different DLLs we use.
But with Windows Server 2008 x64 both, the x86 and the x64 Versions refuse to start.
When i start the x86 Version of the program a Dialog appears:
<myApp> has stopped Working.
The EventLog contains a message:
Faulting application myapp.exe, version 1.0.0.0, time stamp 0x4bcb37ca,
faulting module MSVCR80.dll, version 8.0.50727.4053, time stamp 0x4a594c79,
exception code 0xc000000d, fault offset 0x0001ce0b, process id 0x29c,
application start time 0x01cb0329976cfc68.
\Windows\winsxs contains a directory
x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4053_none_d08d7da0442a985d
Using sxstrace (first trace, then parse) a log file of 3 Bytes length is created containing non readable characters. Behavior of the x64 Version is similar. Also all demo programms from the 3rd Party Dlls are working properly. Any hint ?
It doesn't look like a side-by-side error. The exception code is STATUS_INVALID_PARAMETER, "An invalid parameter was passed to a service or function." That doesn't help. You'll need a debugger, probably with the Windows debugging symbols. Make it stop on the first-chance exception.