Develop Reference

Defending against "unclean" local builds?

(This is about local builds on dev machines, NOT builds being done externally on a build server as blessed builds.)
In normal Visual Studio/C# development, the local build system "just works." However, on rare occasions***, the built code behaves erratically. (Erratically = not as the source code says) Maybe it produces weird errors, produces output that shouldn't be possible, or acts as though recent code changes never happened. These builds can be remedied by doing a clean/rebuild. However, since many solutions take drastically longer to do a full clean/rebuild than to trust the standard build system and simply "Build",
doing a full clean/rebuild every time isn't a practical option.
The problem comes when one of those "erratic" builds gets made and issues are seen. Typically, the bugs get spotted, and developer resources start focusing on how this bizarre behavior could be happening based on the source code used to create it. Since the initial developer can't figure out how the erratic behavior came from the source code, more resources get called in to hunt in futility for the bug in the source code.
Given that once a "non-clean" build goes erratic when built on a certain machine, it will typically continue to build erratically until a clean/rebuild is performed, huge amounts of developer resources can get sucked into the futility before someone throws their hands up and says "I'm going to try some low-probability thing, because we're grasping at straws here", tries cleaning and rebuilding, and suddenly the erratic behavior goes away.
Assuming:
Because of speed, "build" will be chosen over clean/rebuild except when there is an explicit reason for clean/rebuild
The erratic builds happen rarely enough that convincing devs to habitually clean/rebuild daily would be a fruitless endeavor
Making builds and finding errors is a routine part of development and therefore, nothing "stands out" about spotting a build bug that needs to be fixed when the true cause is a corrupt build. Similarly, bringing in additional resources for debugging a hard bug is also routine and not anything that stands out.
Are there ways to defend against this? Are their ways to detect when the temp/cached files that "cleaning" deletes are out of date and problematic?
Are their ways (beyond telling devs to "remember to try cleaning and rebuilding") to prevent a huge snowball of resources from checking the source code for non-existent issues in the code?
***In the last 12 months, I've seen 3 or 4 occurrences of erratic builds wasting >> one developer/day before the cause is found. In the same time, there were probably 3-5000 developer builds that worked normally.

Are there any tools I can use to debug information while attached to a release version?

On a virtual machine, I was able to unintentionally reproduce an issue that only shows up once every or twice a year. The software is in a state where as long as the application is alive and running, I can reproduce the issue. The only problem is everything was built in release. So when I debug with Visual Studio and try to look at some values, I get the following message:
Cannot evaluate expression because the code of the current method is optimized.
To my knowledge, the only way to work around this is to build in debug. Unfortunately, this isn't possible because as soon as I close the application and restart it in debug instead of release, I may never get a chance to reproduce this issue again.
Is there any tool or anything I can do to keep the software in its current state, yet be able to retrieve some of the values I'm interested in? Again, this is a release build, so I realize a lot of necessary information to debug is missing. I do have the release pdbs / source code for the assemblies I'm interested in. Unlikely that it matters, but I'm trying to look at a Window object's IsLoaded property among potentially a few other properties.

Maybe you can try Project Properties - Build - Advanced - Debug info = Full?
According to this answer I think this will allow you to attach a debugger. Other answers in the thread have mixed answers on the effects of this option, but it may be worth a try.

I was finally able to solve this by using Snoop, a WPF Spy Utility. It gave me the value of the IsLoaded property I was interested in. Some peers also mentioned using Ants Memory Profiler, but it is pretty expensive and isn't as trivial to use.

I've found a bug in the JIT/CLR - now how do I debug or reproduce it?

I have a computationally-expensive multi-threaded C# app that seems to crash consistently after 30-90 minutes of running. The error it gives is
The runtime has encountered a fatal error. The address of the error was at 0xec37ebae, on thread 0xbcc. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
(0xc0000005 is the error-code for Access Violation)
My app does not invoke any native code, or use any unsafe blocks, or even any non-CLS compliant types like uint. In fact, the line of code that the debugger says caused the crash is
overallLength += distanceTravelled;
Where both values are of type double
Given all this, I believe the crash must be due to a bug in the compiler or CLR or JIT. I'd like to figure out what causes it, or at the very least write a smaller reproduction to send into Microsoft, but I have no idea where to even begin. I've never had to view the CIL-binary, or the compiled JIT output, or the native stacktrace (there is no managed stacktrace at the time of the crash), so I'm not sure how. I can't even figure out how to view the state of all the variables at the time of the crash (VS unfortunately won't tell me like it does after managed-exceptions, and outputting them to console/a file would slow down the app 1000-fold, which is obviously not an option).
So, how do I go about debugging this?
[Edit] Compiled under VS 2010 SP1, running latest version of .Net 4.0 Client Profile. Apparently it's ".Net 4.0C/.Net 4.0E, .Net CLR 1.1.4322"

I'd like to figure out what causes it, or at the very least write a smaller reproduction to send into Microsoft, but I have no idea where to even begin.
"Smaller reproduction" definitely sounds like a great idea here... even if "smaller" won't mean "quicker to reproduce".
Before you even start, try to reproduce the error on another machine. If you can't reproduce it on another machine, that suggests a whole different set of tests to do - hardware, installation etc.
Also, check you're on the latest version of everything. It would be annoying to spend days debugging this (which is likely, I'm afraid) and then end up with a response of "Yes, we know about this - it was a bug in .NET 4 which was fixed in .NET 4.5" for example. If you can reproduce it on a variety of framework versions, that would be even better :)
Next, cut out everything you can in the program:
Does it have a user interface at all? If possible, remove that.
Does it use a database? See if you can remove all database access: definitely any output which isn't used later, and ideally input too. If you can hard code the input within the app, that would be ideal - but if not, files are simpler for reproductions than database access.
Is it data-sensitive? Again, without knowing much about the app it's hard to know whether this is useful, but assuming it's processing a lot of data, can you use a binary search to find a relatively small amount of data which causes the problem?
Does it have to be multi-threaded? If you can remove all the threading, obviously that may well then take much longer to reproduce the problem - but does it still happen at all?
Try removing bits of business logic: if your app is componentized appropriately, you can probably fake out whole significant components by first creating a stub implementation, and then simply removing the calls.
All of this will gradually reduce the size of the app until it's more manageable. At each step, you'll need to run the app again until it either crashes or you're convinced it won't crash. If you have a lot of machines available to you, that should help...

tl;dr Make sure you're compiling to .Net 4.5
This sounds suspiciously like the same error found here. From the MSDN page:
This bug can be encountered when the Garbage Collector is freeing and compacting memory. The error can happen when the Concurrent Garbage Collection is enabled and a certain combination of foreground Garbage Collection and background Garbage Collection occurs. When this situation happens you will see the same call stack over and over. On the heap you will see one free object and before it ends you will see another free object corrupting the heap.
The fix is to compile to .Net 4.5. If for some reason you can't do this, you can also disable concurrent garbage collection by disabling gcConcurrent in the app.config file:
<configuration>
<runtime>
<gcConcurrent enabled="false"/>
</runtime>
</configuration>
Or just compile to x86.

WinDbg is your friend:
http://blogs.msdn.com/b/tess/archive/2006/02/09/net-crash-managed-heap-corruption-calling-unmanaged-code.aspx
http://www.codeproject.com/Articles/23589/Get-Started-Debugging-Memory-Related-Issues-in-Net
http://www.codeproject.com/Articles/22245/Quick-start-to-using-WinDbg

Download Debug Diagnostic Tool v1.2
Run program
Add Rule "Crash"
Select "Specific Process"
on page Advanced Configuration set your exception if you know on which exception it fails or just leave this page as is
Set userdump location
Now wait for process to crash, log file is created by DebugDiag. Now activate tab Advanced Analysis, select Crash/Hang Analyzers in top list and dump file in lower list and hit Start Analysis. This will generate html report for you. Hopes you found usefull info in that report. If you have problem with analyze, upload html report somewhere and place url here so we can focus on it.

My app does not invoke any native code, or use any unsafe blocks, or
even any non-CLS compliant types like uint
You may think this, but threading, synchronization via semaphore, mutex it any handles all are native. .net is a layer over operating system, .net itself does not support pure clr code for multithreading apps, this is because OS already does it.
Most likely this is thread synchronization error. Probably multiple threads are trying to access shared resource like file etc that is outside clr boundary.
You may think you aren't accessing com etc, but when you call certain API like get desktop folder path etc it is called through shell com API.
You have following two options,
Publish your code so that we can review the bottleneck
Redesign your app using .net parallel threading framework, which includes variety of algorithms requiring CPU intensive operations.
Most likely programs fail after certain period of time as collections grow up and operations fail to execute before other thread interfere. For example, producer consumer problem, you will not notice any problem till producer will become slower or fail to finish its operation before consumer kicks in.
Bug in clr is rare, because clr is very stable. But poorly written code may lead error to appear as bug in clr. Clr can not and will never detect whether the bug is in your code or in clr itself.

Did you run a memory test for your machine as the one time I had comparable symptoms one of my dimms turned out to be faulty (a very good memorytester is included in Win7; http://www.tomstricks.com/how-to-test-your-ram-or-memory-with-windows-memory-diagnostic-tool-in-windows-7/)
It might also be a heating/throttling issue if your CPU gets too hot after this period of time. Although that would happen sooner imho.
There should be a dumpfile that you can analyze. If you never did this find someone who did, or send that to microsoft

I will suggest you open a support case via http://support.microsoft.com immediately, as the support guys can show you how to collect the necessary information.
Generally speaking, like #paulsm4 and #psulek said, you can utilize WinDbg or Debug Diag to capture crash dumps of the process, and within it, all necessary information is embedded. However, if this is the very first time you use those tools, you might be puzzled. Microsoft support team can provide you step by step guidance on them, or they can even set up a Live Meeting session with you to capture the data, as the program crashes so often.
Once you are familiar with the tools, in the future you can perform similar troubleshooting more easily,
http://blogs.msdn.com/b/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx
BTW, it is too early to say "I've found a bug". Though you cannot obviously find in your program a dependency on native code, it might still have a dependency on native code. We should not draw a conclusion before debugging further into the issue.

Decimal Ternary Not Working

I'm trying to use a ternary to assign a decimal type. It's not working for me. Am I going crazy?
Here's a screen shot of my debug. You can see the value of everything before I step.
And after I step here is the value. It isn't even one of the viable options (i.e. 1 or 2000).
Is there some strange limitation with decimals that I don't know about? When I break it out into its full if/else logical representation it works fine. The only thing I can guess is that I did recently install .NET Framework 4.5.
UPDATE
I've cleaned the solution and made sure I was running on code that was compiled in debug mode as recommended in the comments. Neither of those seemed to change anything.
I started to get curious though when I noticed all my unit tests were still passing. After a little more sleuthing I found that when I stepped one more time (i.e. stepped over memberItems.Add) price magically has the right value in it.
Does .Net do some kind of a delayed resolution of ternary operators similar to the yield command in iterator blocks? I've never noticed it before now but I don't know what else it could be. I suppose I could also still be running on code compiled in release mode accidentally. I've made dumber mistakes after triple checking myself.

Impossible to diagnose code from a screenshot, so just a guess.
You cannot always completely rely on what a watch expression tells you. The first possible failure mode is debugging code that was optimized. A local variable like price will very typically be optimized by the jitter optimizer to be stored in a cpu register instead of the stack. The watch expression will show you the stack location value, not the cpu register value. With 0 being a common result. The only real defense you have against this is only debugging code that was built by the Debug configuration.
Second failure mode is the way watch expressions are evaluated. The CLR starts a dedicated thread when it detects an attached debugger. The debugger can then use this thread to evaluate watch expressions. This can go wrong if a variable has any thread affinity. Common cases are variables that are [ThreadStatic] or are properties of COM objects.

I had the same problem and I also thought I was going crazy.
I found that changing my ASP.NET app to use "Visual Studio Developer Server" instead of IIS fixes it. Pity because I like using IIS as that's closer what's happening in production.

C# app runs with debugging, but not without [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 7 years ago.
Improve this question
I'm running a (mostly) single threaded program (there's a main thread that does everything, the others only read stuff). I can get the application to run fine in VS2008 after a minor change (I changed the text of a form, and tab order of another form), but I can no longer get it to work outside of the debugger. Does anyone know what would cause this?
Clarification: Release mode, launched with debugger (F5) works. Debug mode, lanuched with debugger (F5) works. Debug executable, or release executable launched outside of VS or with Ctrl+F5 fail.
It uses Microsoft's Virtual Earth 3D, and it seems to crash just when the 'ring of hope' (loading ring) is about to complete.
Event log says: ".NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (000006427F44AA6E) (80131506)"
Culprit: this line:
this.loader = PlugInLoader.CreateLoader(this.globeControl.Host);
Causes it to fail. However, the form that was working uses the exact same line without an issue. This line is nesseccary for the program to function. I have no idea what it's doing.
Another Lead the error seems to be inside the .NET framework. Application worked on another machine, attempting reinstall. Update: didn't make a difference, although when I repaired VS it kept telling me Visual Studio was crashing even though I wasn't running it.
Error
When I launch the program after a couple minutes I get:
Application has generated an exception that could not be handled.
Proccess ID=0x9CC (2508), Thread ID =0xF0C(3852).
Click OK to terminate the application.
Click CANCEL to debug the application.
The disassembly is bizarre:
0000000077EF2A90 int 3
0000000077EF2A91 int 3
0000000077EF2A92 int 3
0000000077EF2A93 int 3
0000000077EF2A94 int 3
0000000077EF2A95 int 3
0000000077EF2A96 xchg ax,ax
0000000077EF2A9A xchg ax,ax
0000000077EF2A9E xchg ax,ax
0000000077EF2AA0 int 3 <-- Crashes here
0000000077EF2AA1 ret
It repeats that same code block several times (minus on ax exchanging with itself)
Besides my computer, it has worked on every machine I've tested it on, except for a VM on my machine which won't install the .NET framework because setup downloads 0 bytes out of 0 bytes for the framework)...lovely windows.

I've had similar issues where timing conflicts were causing the failure, and my debugging (breakpoints and stepping through the code) forced the code to run in the correct order.

Try take off optimizations from the Release build (in the project settings) and see if that helps.

I fixed it, the .NET 2.0 Framework was corrupt and when I reinstalled it, everything magically started working again.

I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.
Switch to release mode
Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
Run executable in debugger, ignore the warnings from VS that there's no debug info
It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong
EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)

Here is a support article with that error. Does that apply?
Perhaps the debugger is eating an excaption the VE3D API is throwing. In VS, do a ctrl+alt+e and change it to break whenever any exception is thrown. This can be tedius b/c it will break on all your try catch blocks, but it might give you some information.
Here is some info. about that PlugInLoader. It seems to imply it must be called from the FirstFrameRendered eventhandler. Perhaps one of your forms is doing that and one not?

Search for #if(DEBUG) directives?
Search for Debug.Assert(?
Have you googled the error? I found this thread (admittedly not horribly helpful)

I once had a similar problem with exactly the same behaviour using a plug-in-system. When loading a plug-in from a MarshalByRef-object (see example code below), it seems as if .NET creates a new AppDomain or Context for the loaded assembly. (Can anyone confirm this? I've not found any source regarding this.)
public class ProxyAssemblyLoader : MarshalByRefObject {
public Assembly GetAssembly(string path) {
return Assembly.LoadFrom(path);
}
}
Furthermore in my case the plug-in loads a different version of the mscorlib. (My app is CLR2 and the loaded is CLR4) Afterwards I used the plug-in by reflection and tried to access a value of the new mscorlib, which was loaded from the other application domain. Usually both should be usable because the mscorlib is a commonly used assembly and only loaded once (see Global Assembly Cache). But it seems as if this is not the case. But in general Microsoft advises to avoid that.
I've not exactly figured out what the problem was, but I figured out the call that causes the application to crash without any hint. Why without any hint? It crashed without any hint, because the thrown exception was only available in "the other" appdomain and not available for the main/default app domain.
The taken action was just implicit copying the value of another appdomains assembly to a local untyped value (object) in the default appdomain. This was enough to get a type identity mismatch error due different versions of the assembly. It seems as if Visual Studio could handle it, but if the application runs standalone it crashes.
This may also explains why you needed to reinstall your .NET. Maybe your installed .NET-Framework was a beta or something like that, which contained a minor difference.
In conclusion some general solutions for the problem could be:
Avoid using different versions of assemblies with different versions of the same type.
In other cases may try to load both assemblies inside the same appdomain. (As far as possible regarding the probing context.)
A solution for cross appdomain communication could be serialization of the values.
(Make sure that the correct .NET-Framework Non-Beta Version is installed.)

we found and fixed this issue with MSFT, we faced this problem with VSTO development.
Apply the following patch from MSFT.
http://support.microsoft.com/kb/975954
http://support.microsoft.com/kb/974372

One thing left I think is to use WinDbg to try and debug it. Here are some links on how to use it:
http://www.codeproject.com/KB/debug/windbg_part1.aspx
http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx
http://blogs.msdn.com/tess/ (good blog about debugging in general in windbg)
Thinking about it, it could also be some service or something that's clashing. Try stopping all unneeded services and closing unneeded programs (including startup ones) and see what happens then.

I had the exact same issue with one of my console applications. I determined that it was my antivirus (Avast) that was causing the issue.
Add the BIN folder to the exclusion list and disable "DeepScreen".
Then rebuild the project and try again!