While I try to debug a program in VS2010 I get the following message:
I have tried to:
restart the computer
move all files to a new sulotion
debug a different program
debug this program on a different computer
the first two mattered nothing, the lost two worked.
what's wrong with my computer and how do I fix it?
I'm using VS2010 pro, running on win7.
I uploaded the project I tried debugging to google drive, if any one wants to see it.
I started getting this error today. I checked multiple applications, and all failed. Visual Studio itself was crashing. The application was working 2 days ago. I had to copy msdia100.dll from my laptop and the run regsvr32 as described above. When I compared the files, they had the same time stamp and the same size, but the contents were completely different. No idea how the change happened. Everything appears to be working after replacing the DLL.
Related
I have an Inncoscript that works fine when I start it from my PC harddrive. But when it is downloaded from a server by a web site, it gives the following error message: "This app can't run on your PC." The strange thing is that it has worked before, some months ago. I have not registered the program Innoscript is supposed to launch at Microsoft yet, because it costs a lot of money and because it still is in the testing phase. I get warnings and am asked if I really want to run the Innoscript program. After clicking yes, the error message occur. The actual program to be launced is made in C by Visual Studio, and I am using Windows 10.
Thanks in advance.
I found the solution. The path had been changed.
My solution consists of a 195 (not a typo) C# MVC application projects w/ some ASPX pages as well running on VS2017 on Windows 10. Its nothing bleeding edge. A days ago, "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Microsoft.VisualStudio.Web.Host.exe" started taking over my machine.
Here is what I have experienced.
The app (Microsoft.VisualStudio.Web.Host.exe) will keep VS2017 from loading a solution I'm trying to open.
The only fix is to kill the offending exe via Task Manager.
The app will keep VS2017 from exiting when a solution I'm using is open.
The only fix is to kill the offending exe via Task Manager.
When trying to build, things slow to a grind.
The only fix is to kill the offending exe via Task Manager.
The offending app will use as many resources as possible.
I've done Win10 an Symantec virus scans on the offender. Both scans came back negative.
I've tried adjusting the app's settings in task manager so that only one or two cores can be used by the process. This helps, but sometimes I still have to kill the app to get things working in VS2017.
Whenever I kill the app, it comes back within 30 seconds.
Sometimes, things work fine. No discernible reason why.
iisreset does nothing.
I resorted to renaming the EXE file, that way it couldn't attack me again.
That seems to work, but its a hack.
Does anyone know what the root cause is, and how to resolve it?
I am just trying to run an application locally. I got the source code from source control and when I try to debug it, VS gives an error saying MSVSMON.exedoes not appear to be running on the remote machine.
Not sure why I am getting this error when I want to debug locally.
It is a windows application that I am trying to run.
PS: The same application on another machine seems to be working i.e. a friend is able to debug whereas I can just run it not debug
Had this problem recently and it drove me nuts for a while; and there are a lot of results if you Google it - none of which helped me. In my case if I changed the build target to 32 bit instead off 64 it solved the problem for me.
No idea what the root cause of the problem is though.
Visual Basic 6 is crashing after a new build of my program. Whenever I Start (F5 or Ctrl-F5) my program after making changes to the code, VB6 crashes with the following message:
An unhandled win32 exception occured in VB6.EXE [XXXX].
I can't make any pattern out of XXXX. It's been 5168, 5012, 1488, etc; it changes every crash.
The JIT debugger then offers to let me debug VB6 in VS2010 (which shows nothing but a bunch of disassembly.) If I say no, VB6 shuts down. I can then open and Start my program immediately, and it runs just fine; my changes from before the crash were saved. Alternatively, I can make changes, save them, exit VB6, restart VB6, then run them without a problem. But it seems like as soon as I make any changes, a "crash" flag is set, and if I try and build it before restarting VB6, it simply dies.
I'm only having this problem with specific projects. Most projects work completely normally. It's just this one, and it's branch, that both act in the same manner.
Does anyone have any clue what's going on? Obviously, saving works. And building works. And running works. They just don't seem to work together.
I reinstalled VB6 to no avail.
I ended up on this page after installing VS2010, and just one of many VB6 project wouldn't compile.
Simply go to Project Properties / Compile tab, and uncheck "Create Symbolic Debug Info".
Hope it works for you.
Try to open vb6 project with compability mode as XP. We had some issues related to "make exe" command. Then I started to run VB6.exe with XP compability mode.
Since you're asking for any clues, possible clues may include:
The surprises VB6 experiences when run on Vista/7. Try running elevated/remove elevation.
Same, but applied to a third party ActiveX control you're using.
Not having the Service Pack 6 installed. Install it.
Subclassing issues. Make sure your subclassing, if any, is actually correct.
Whatever problems you'll never figure out. Try reinstalling.
Reinstall VB6, delete the workspace files and then create a new project adding in all your current code files. Then go out and get a job where they use a modern SDK :)
I have a VB6 app that formerly worked perfectly on a Vista machine as a scheduled task, but it will no longer open on the same machine. The app generates export files in a specified folder with no direct output on the screen. I get no errors, no missing references, just absolutely nothing.
The machine is running Vista Business 32-bit, UAC is disabled with a single administrator account, and automatic updates are turned off. The app resides in a non-protected folder, and the export files are put in a folder on the desktop. The client swears that the only change they made to that computer since I installed this app was installing Norton Antivirus, which has never caused problems before with our software.
In addition to the normal VB6 references, the app references Microsoft Scripting Runtime (scrrun.dll), and Microsoft DAO 3.6 (dao360.dll). Both of these files are present and registered on the target machine, along with all the other VB6 dependencies. I added MsgBox statements at the beginning of Sub Main() just to see if anything is being executed, and its not. Disabling Norton yielded no results, nor did reinstalling VB6 runtime to rule out any corrupted libraries. Not once did I get any messages, error or otherwise from my app.
I've never had an issue like this before and I'm completely stumped. Is there anything else that could be causing this?
Edit - The app does not run even when I run it manually, so the part about it being a scheduled task is irrelevant to my problem, sorry for including it.
The user has full administrator credentials, no compatibility mode was needed on the initial test which at the time, was done on this very machine I am having the problem on. For grins I tried compatibility mode for XP and 2000, still nothing.
Try to inspect - if you can access them - the Event Viewer messages. Maybe you will find some tell-tell signs in there...
You could try running the program in Windbg, a free standalone debugger from Microsoft. Compile your VB6 EXE into native code with symbols (create PDB files) and you will be able to debug your application in Windbg.
I would guess one of two things will happen.
Windbg will fail to load the EXE. Presumably with an error message that will identify your problem.
Windbg will load the EXE, and you can single-step through to see what happens.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
Has the user changed their password? That will cause the scheduled task to fail until they re-enter the password on the task.
Have you tried running the process directly, instead of as a scheduled task? I'm far from an expert, but it may be that any errors being generated are not showing up because the program is running as a task.