When I run command line application (executable generated using visual studio 2008) on non development windows 7 machine it gives following run time error "application has requested run time to terminate in unusual way. Please contact application support team for more information". It runs fine on a development machine.
With VS 2005 and VS 2008, Visual C++ used a side-by-side versioning scheme that requires manifest entries embeddded in the EXE to really work correctly in all cases. It's possible you are dealing with one of these. See these articles for details on debugging these side-by-side issues.
Diagnosing SideBySide failures
Part 1: Troubleshooting VC++ Side by Side Problems
Part 2: Troubleshooting VC++ Side by Side Problems
Note that with VS 2010 and later, Visual C++ no longer uses this side-by-side scheme. That said, there are still lots of reasons to use embedded manifests anyhow. See this article.
Related
For over a month now I've been experiencing problems with VS2017 on my home PC. I even tried submitting the feedback to Microsoft. There's more info about the problems I'm experiencing there.
The problem:
The gist of it is that VS is eating RAM like crazy. As soon as I start opening files, adding new files, using IntelliSense, building or (especially) debugging, the RAM usage skyrockets.
After that it's only a matter of time before the VS crashes and restarts without any error message. Though there are numerous error messages throughout these breif ~20min I have with each session.
Additional details I observed:
Doesn't happen with Python projects, as these don't have to be built constantly. It might be eventually happening if you debug a lot, but I didn't have the chance to check that because most of my Python coding is debugged on an external device
Size of the loaded solution doesn't matter;
UWP and WPF seem to crash the most. Console Projects take longer to crash.
Also affects .NET Core;
It doesn't matter which version of .NET Framework I use;
VS2015 worked perfectly, but I don't have it anymore after the format
What I already tried:
I reinstalled VS;
I refreshed Windows;
I reinstalled Windows;
I checked my drives and RAM for issues - none found;
I switched from Community to Enterprise;
I tried disabling extensions;
I applied some shady hotfix I found somewhere;
Finally, I installed Rider which seems to be the best solution as of now. It still lacks many important features, though.
Is there anything else I can do/try/check? Did anyone experience (and fix) a similar issue?
Cheers!
You get a System.OutOfMemoryException, this means your Visual Studio runs out of free virtual address space (4GB on 64 Bit Windows for the 32Bit Visual Studio because Visual Studio is configured to be large address aware and MS refuses to release VS as 64Bit program which would fix this issue).
To analyze the memory usage, you need to run WPRUI.exe (part of Windows Performance Toolkit (which gets installed by VS2017) for some scenarios, if not, install it on your own), select Reference Set (Note: expand the Resource Analysis entry first to see all options).
and click on Start. Capture the memory usage grow for some 100s of MB and click on Save.
Open the generated ETL with the analyzer (WPA.exe) and analyze what the process devenv.exe is doing.
Also zip the ETL + NGENPDB folder (important) as zip and attach it to your bug report so that Microsoft can analyze it.
Visual Studio 2012, VS 2012 Command Prompt, VS 2010 Command Prompt, and a C++ console application compiled in 64-bit with VS 2012 are all reading an out of date instance of various registry keys. Each application (i.e. VS 2012, the command prompts, and the compiled app) all seem to have their own version of this out of date registry. Below are the symptoms I'm seeing and my various attempts to fix it.
I've both added new registry entries and updated the data in existing ones and all appear updated in HKLM\Software\ viewing them with RegEdit and using 'reg query ' in a normal console window.
Using the VS Command Prompt I perform the same query and get registry entries prior to my updates. If I open up a VS 2012 command prompt and perform edits using command line arguments the registry for that VS 2012 command prompt is now different than the registry read by the VS 2010 command prompt. It is also different from the VS 2012 IDE and the application built from VS 2012. They seem to have their own instances of whatever version of the registry they are reading from.
Finally, I opened up the Visual Studio 2012 command prompt and typed Regedit. It opened up RegEdit and it was viewing the old registry! All of the stale values within HKLM\Software\ were present - a seemingly completely separate version of the registry. Where is it getting this from?
My environment: Windows 7 Enterprise, VS 2012 Ultimate, console application built in 64-bit.
It should be noted that I have not made any major environment changes that I recollect and this is a new issue on my previously working development system. My colleagues have the same/similar environment and hardware setups with the same code base and have never encountered or seen this issue.
Things I've tried.
The almighty reboot
Uninstalling / Re-installing VS Studio 2012 as well as wiping out my code base, pulling it fresh and rebuilding (brute force I know...).
Checking the Registry for Wow6432Node keys to see if the reads/writes are getting redirected (I do not have a HKLM\Software\Wow6432Node and no other instances of that key have the old stale data or much else for that matter)
Searching the entire registry for the stale keys/values/data I'm seeing (not found anywhere)
Turning off virtualization using 'reg FLAGS hklm\software\ SET DONT_VIRTUALIZE DONT_SILENT_FAIL RECURSE_FLAG' as well as variations of this with one flag at a time.
Writing and debugging a unit test to try and determine anything.
VS 2012 safe mode
VS 2012 logging to see if the log file could shed any light on the problem.
Cursing (quietly because I'm at work)
Bribes (my workstation has yet to respond to these attempts)
Any help would be greatly appreciated. I'm close performing a clean Windows installation on my workstation but would rather save myself the time and trouble of setting everything up again :)
I've just installed the Visual Studio 2012 RTM on a Windows 7 x64 desktop.
Unfortunately, I'm very underwelmed by the performance of the out-of-the-box installation. Everytime I try to rename a file in the solution explorer, change to a MVC cshtml editor, open a designer view, or intellisense pops up when I start typing with the c# editor, the whole visual studio applications hangs for 5-10 seconds.
There are no customizations, plugins, extensions enabled here that do not get applied with the standard installation.
Has anyone else experienced this? Has anyone else found a way to log the application faults which occur, or detect the hang. I need some way to determine what is going wrong, in order to identify what needs to be altered to rectify the installation.
The problem is you are consuming the lot more resources of the system which is causing hung state of VS. Please close any of other application who is using more RAM. You can take the help of Task Manager to close those application. Please keep in mind if you are running SQL standalone database instance services then its also causes the hand issue. The best is keep you system free from running unuseful application or Go for System upgrade. :-)
Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.
I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.
I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?
I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.
To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.
I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.
The solution was:
Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
Check the box "Show advanced build configurations" and click OK
Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
Now rebuild the project
Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.
More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?
Good luck
There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.
I've developed an application in VS 2003 (C++). But while running in a fresh windows xp machine, getting error:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:
This application has requested the Runtime to terminate it in an unusual way....
What will be the reason for getting this error and how can I solve it? Please help.
This is a very generic error so it is not easy to solve from this information but I can give you a few things to try.
First check that the program runs fine on your developer machine - if not run under the debugger and trap the specific error.
If this problem only occurs on the clean machine it probably does not have the correct runtimes installed.
Your application will depend on a number of dlls that ship with visual studio, you will need to install these on the clean machine.
Your can run depends.exe from http://www.dependencywalker.com/ this will tell you what dlls cannot be found.
These dlls will be on your developer machine, you can either package the yourself in an installer or find the correct redistributable from microsoft.
Another thing to check - have you hardcoded any file locations? e.g. your application could try and open a file, resource, registry key - something that does not exist in your clean machine - if the code does not check for failure you would then probably crash at some point after the read failed to happen.