Visual Studio 2015 Error: “csc.exe” exited with code 255 - visual-studio

Every time I try to run my code, I am having this error: "Csc.exe" exited with code - 255.
I removed and re-installed Visual Studio 2015 and it did not help.

Does csc.exe succeed with different code?
It is possible that you’ve found a bug in the compiler that causes it to crash when trying to compile your particular program. To see if this is the case, create a new “Console App” project with Visual Studio (VS) and see if the default app in the template compiles and runs. If that works, then your code might be triggering a csc.exe crash. If that doesn’t work, your VS install might be completely broken in which case I would recommend uninstalling and reinstalling VS (but you already tried that). If you cannot get VS to run even simple programs on your computer, you’ll need to try to track down why it is crashing and see if it is something you can manually fix. If your system is messed up enough and it is not worth tracking a fix down, you might consider reinstalling Windows (using the “Reset” feature).
Another thing to try is running your code on another computer with VS installed. That can help determine if the issue is your code triggering a compiler error versus your computer being messed up.
If csc.exe only crashes for your particular code, then that is a bug in csc.exe. If there is an issue with your code, csc.exe should generate a nice error explaining the issue with your code instead of crashing.
It is also possible that your code is valid but a compiler bug causes csc.exe to crash. An example of this (with VS 2017 and csharp7) is roslyn#19182. If this is the case, you might try using the VS feedback (frowny face/feedback button in the upper right hand corner) feature to report the issue so that the VS developers know about it. Also, you might be able to poke your code around until suddenly VS starts running successfully. If this is the issue, it might be hard to guess why csc.exe is crashing, but, if you can, try to isolate the issue. For example, if csc.exe was running fine before you made some changes to your code, look at the changes you made and see if undoing them results in csc.exe running successfully again. Then try to make a new, minimal repro which causes csc.exe to crash and send that as feedback using VS’s feedback mechanism or by reporting a bug against the roslyn project. You might also ask a new question here about why that particular code causes csc.exe to crash. With particular code, people might be able to guess why csc.exe can’t handle it and suggest workarounds to use while waiting for the VS team to release a fix.
As it is, your question does not have enough information to guess why csc.exe was crashing for you. Hopefully this answer provides some guidance on what steps you should take if you ever end up in such a situation.

Related

Visual Studio Debugger Freezing for specific solution

I'm running in to an issue where my solution freezes when debugging. If I place a breakpoint at the beginning of the solution, it wont freeze and will allow me to either continue or step through just fine. With this solution however, I need it to start from a specific point in the code. When I try to start it from that specific point, it'll freeze, and the output and locals box will have a popup in each saying "Busy..". It did not have this issue a few days ago, but just started yesterday.
It only occurs to this specific solution (I can debug other solutions just fine). Using C#/.NET mostly.
Remedies I've tried: Clean/Rebuild, repair on installer, uninstall just app, uninstall app and associated files, running Release, code cleanup, upgrading/downgrading vos, placing breakpoint at beginning then jumping to next breakpoint at specified point, removing antivirus software temporarily
Running latest version of Visual Studios 19 Community at the moment.
I didn't find the solution necessarily, but deemed it to be an issue with the "Locals" box that displays all your local variables and values. If I close out of this, I can continue with debugging. From further research, it seems that tool has been known to be pretty buggy.

Debugging Spawns A Non Terminable Process, and CLI not launching

I've been fighting this little problem for a while now, so I'm really hoping I can get some help. I've been looking for a solution to this, and I found this SO question: Debugging doesn't start.
My issue is somewhat similar to the issue discussed here, except that my issue is a two-parter.
Part 1: Similar to the issue discussed on the other question. (Debug Window Doesn't show up)
When I attempt to launch my Windows 32 console application project (The simple kind that opens in the windows CLI). The CLI (or CMD) window doesn't open, and windows idles giving me a spinning cursor wheel. Visual Studio IDE (I'm using VS 2013 Community) becomes unresponsive and I cannot access any menus, or use any hotkey to "Stop Debugging". One difference from the provided SO question though, is that when I try to launch "MyProject.exe" from my project's "Debug" folder I get the same result as attempting to debug in the IDE.
Part 2: Unkillable Process
When I try to close my debug application in the windows task manager, it is not listed as an ongoing process. However, whenever I try to manipulate, delete, or otherwise modify my Project.exe application (in my Project's "Debug" folder), windows informs me that the application is in use. Confused by this, I downloaded two applications. The first was Process explorer, which showed me that I did in fact have 2 instances of "MyProject.exe" running. The second was Process Hacker, which also showed me 2 instances of "MyProject.exe". However, neither of these programs were able to terminate either of the "MyProject.exe" processes.
I am capable of terminating the processes for visual studio and restarting the IDE, however, because the "MyProject.exe" processes are still running. Building always fails with the error
"Error 1 error LNK1168: cannot open C:\Users\Brandon\Desktop\MyProject\Debug\MyProject.exe for writing"
Whenever I restart my computer, the lock files (as expected) are removed, and the "MyProject.exe" processes disappear. I can restart VS and everything works, but if I try to Debug (pressing "Start Debugging" or F5) the same issue occurs.
A process of my program is started ("MyProject.exe"), but the CLI window where my program's text should appear doesn't show up. Visual studio locks up, and "MyProject.exe" persists until the next restart because "MyProcess.exe" cannot be terminated.
My solution configuration is set to "Debug", Solution Platforms = Win32.
I have tried creating a new blank console project in VS 2013 and I get the same result: code builds fine, but I have the same debugging issue. I get an identical result with a quickly assembled "Hello World" project.
Sorry for being a noob, but honestly. I really don't know what's going on, so any help is greatly appreciated.
(Note: Running Windows 10 with VS2013)
EDIT (UPDATE):
So, I'm having the same problem with several programs in Windows 10 (most notably Allegorithmic's Substance Painter). So it looks like this may actually be an OS problem. Several of my programs whenever I try to launch them do the same thing...the program acts like it's going to launch, but then no usable window appears. Looking at my processes I can see that the process has been started, but it is once again unkillable. For reference, I am using Windows 10 Version 1511 (OS Build 10586.17).
I believe your problem might be Avast, if you are running it. I had exactly the same issues until I uninstalled it. Had upgraded to Win10 and VS2013 just froze, same as you described.
Cheers.

Code doesn't work in debug

i coded a big project in c++ that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs after 5 seconds. It just doesn't reply anymore and is tagged as inactive in taskmanager. I tried to analyse the error with the windows debugger tools and application verfier, but i found nothing. Even when I set the "_NO_DEBUG_HEAP=1", the error doesn't occur, it just happens when I start it with ctrl + f5 or outside from visual studio. I'm not even sure if the _NO_DEBUG_HEAP works... Anyone have an idea what could be wrong ?
Any number of things may cause this.
Based on my passed experience, I suggest tackling this by removing code until the behaviour disappears... then determining why removing the code in question corrected the behaviour. (the removed code may not have been the cause, only a catalyst for the symptom)
If I was tasked with taking a quick glance to spot the error, I would think to look for buffer overrun related issues. This type of error has more safeguards in debug than executing a final build. That's just a stab in the dark based on buffer overruns being a common issue that kinda fits the symptom.
-dm
Common things to check:
Are you sure your application is setting any memory used to zero,
if it is assuming the memory has to be zeroed out?
Visual Studio might be initializing the memory given to the
application.
Is all the memory allocated being deallocated?
There are no un-initialized pointers being used?
There are no un-initialized variables being used?
64 bit exe crashing outside visual studio but working inside visual studio
Does the problem only happen on one computer?
You can use check_heap to check the validity of the heap
in the program:
Program crashes only in Release mode outside debugger
You can use the Windows debugging tools to show heap
corruption - there is a tool called "gflags" that comes with the
Microsoft "Standalone Debugging Tools for Windows"
https://msdn.microsoft.com/en-us/windows/hardware/hh852365
This URL shows how to run gflags against your .EXE:
Visual Studio - how to find source of heap corruption errors

mt.exe unable to terminate

Sometimes when I compile C++ code using nmake, the build process gets stuck at the manifest tool mt.exe (see the bottom of this screenshot - http://i.stack.imgur.com/pgyzT.png). It just never finishes, but if I cancel the build process and start again, it may run past the last point but get stuck again at another seemingly random mt.exe process. This makes building big software very cumbersome, as I need to "monitor" the build process to know when to cancel and start again from the beginning.
I'm clueless as to what could be the reason to this behavior. Has anybody encountered this problem before?
Edit: I'm using Windows 8 x64, the mt.exe comes from Windows SDK 6.0A.
I had similar problems with msbuild getting stuck at random points. Never found out what caused it, but a workaround that worked for me was to disable parallel building of projects.
Trying disabling your anti-virus on-demand scanning when building. I have seen some anti-virus software block access to a file using mt.exe, though usually you get an error instead of a hang.

Side-effect on VS addin already installed, when installing/deinstalling an extra VS package

I noticed that at installation time of a VS package product (like http://www.continuoustests.com/ ) devenv.exe is started
and I notice that sometime my VS addin is loaded (its OnConnection() method is called), and this could provoke a crash.
The problem is about sometime, since I cannot repro the conditions where my VS addin gets loaded.
From my crash log, I know it happens rarely, only with VS2010 devenv.exe, and I know as well it is independent from the machine architecture x86 / x64.
I tried installing/deinstalling extra addins having no VS instance running, or having VS instances running, VS2008 or VS2010.
Does anyone have a clue about how to reproduce the problem when my VS addin gets loaded?
Btw, I am pretty sure to have a fix for the problem, since in OnConnection() I already have code like that...
switch (connectMode) {
case ext_ConnectMode.ext_cm_External: // This setting is no longer used by Visual Studio. (http://msdn.microsoft.com/en-us/library/extensibility.ext_connectmode%28v=vs.80%29.aspx)
case ext_ConnectMode.ext_cm_CommandLine:// The add-in was loaded from the command line, don't support it so far
case ext_ConnectMode.ext_cm_UISetup: // addin loaded for the first time, we don't need it (http://msmvps.com/blogs/carlosq/archive/2008/10/13/the-onconnection-method-and-ext-connectmode-ext-cm-uisetup-of-visual-studio-add-ins.aspx)
return;
case ext_ConnectMode.ext_cm_AfterStartup:
case ext_ConnectMode.ext_cm_Startup:
case ext_ConnectMode.ext_cm_Solution:
break;
}
... but once OnStartupComplete() is called back, I forgot to check the connectMode value I got in OnConnection(), hence the crash.
Anyway being able to reproduce the bug would comfort me in the fix.
Update: 10 October 2011
After more testing and feedback from users that repro the problem, it appears that my theory was wrong: connectMode is actually in the range [ext_cm_AfterStartup, ext_cm_Startup, ext_cm_Solution].
The problem only occurs with VS2010 and comes from the fact the addin has no UI element, provoking something like dte.MainWindow, or HwndSource.FromHwnd(new IntPtr(mainWindow.HWnd)).RootVisual to be null.
I talked with Carlos Quintero http://msmvps.com/blogs/carlosq/, the world expert in VS addin, that has never observed this case. VS2010 shouldn't load any addin in the VS extension install/uninstall scenario, and it seems to occur randomly, or more likely, under unknown and rare conditions.
I'll put yet another try/catch to circumvent yet another VS2010 addin bug :(

Resources