Develop Reference

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.

Wrong line numbers in stack trace

The problem
On our ASP .net website I keep getting wrong line numbers in stack traces of exceptions. I am talking about our live environment. There seems to be a pattern: The stack trace will always point to the line that contains the method's closing curly brackets.
For Example:
public class Foo
{
public void Bar()
{
object someObject = null;
someObject.ToString();
/*
arbitrarily more lines of code
*/
} // this line will be the one that the stack trace points to
}
More details
To be clear: This does not only happen for some method(s), it happens for every exception that we log. So I would rule out (JIT) optimizations here, that might lead to line numbers being seemingly randomly off. What bothers me is, that the wrong line numbers seem to consistently point to the closing curly brackets of the containing method.
Note that before .net 4.6 there actually was a bug in the framework, such that if you compiled targeting x64, exactly this would happen. However, Microsoft confirmed that this has been fixed. Also running a minimal example app for this, reaffirms their claim. But for some reason it still happens on the web servers.
It puzzles me even more that it does not happen in our test and development environments. The test and live systems are pretty similarly set up. The only real difference is that live we are running Windows Server 2012, while on the test system we are still using Windows Server 2008.
What I have checked
pdb files are valid (tested with chkmatch)
Compile time code optimizations are not the issue
The aforementioned bug in .net before 4.6 cannot be reproduced with a minimal example
.NET versions are exactly the same
Build comes from the same deploy script
Any clues towards solving this problem are highly appreciated. If you know anything that we could check, please let me know.

Compilation optimization as well as runtime optimization can change the actual execution, as well as the call stack information constructed. So you cannot treat the numbers that seriously.
More information can be found in posts such as Scott Hanselman's: Release IS NOT Debug: 64bit Optimizations and C# Method Inlining in Release Build Call Stacks.
It would be too difficult to troubleshoot a specific case without touching your bits. But if you know of WinDbg you might dive deeper, by live debugging the application when the exception occurs. Then you can dump the actual jitted machine code as well as other runtime information, so as to determine how the line number is constructed.

Thanks everyone for your help! We found out that the SCOM APM agent running on the machines in production caused our application to log wrong line numbers in the stack traces. As soon as we deactivated the agent, the line numbers were correct.

In latest .NET Core versions (aka .NET 6.0) if you have "Ready to run" JIT optimization enabled (PublishReadyToRun in publishing settings), this essentially renders line numbers inaccurate too.
Disabling it might help. But this comes as a performance trade obviously.

How does running C# app inside a code profiler differ from running one outside code profiler?

I'm trying to understand how a code profiler (in this case the Drone Profiler) runs a .NET app differently from just running it directly. The reason I need to know this is because I have a very strange problem/corruption with my dev computer's .NET install which manifests itself outside of the profiler but very strangely not inside and if I can understand why I can probably fix my computer's issue.
The issue ONLY seems to affect calls to System.Net.NetworkInformation's methods (and only within .NET 3.5 to 2.0, if I build something against 4 all is well). I built a little test app which only does one thing, it calls System.Net.NetworkInformation.IsNetworkAvailable(). Outside of the profiler I get "Fatal Execution Engine Error" occurred in System.dll, and that's all the info it gives. From what I understand that error usually results from native method calls, which presumably occur when the System.dll lets some native DLL perform the IsNetworkAvailable() logic.
I tried to figure out the inside and outside the profiler difference using Process Monitor, recording events from both situations and comparing them. Both logs were the same until just a moment after iphlpapi.dll and winnsi.dll were called and just before the profiler-run code called dnsapi.dll and the non-profiler code began loading crash reporting related stuff. At that moment when it seemed to go wrong the profiler-run code created 4-6 new threads and the non-profiler (crashing) code only created 1 or 2. I don't know what that means, if anything.
Arguably unnecessary background
My Windows 7 included .NET installation (3.5 to 2.0) was working fine until my hard drive suffered some corruption and checkdisk began finding bad clusters. I imaged the drive to a new one and everything works fine except this one issue with .NET.
I need to resolve this problem reinstalling Windows or reverting to image backups.
Here are some of the things I've looked into:
I have diffed the files/directories which seemed most relevant (the .NET stuff under Windows and Program Files) pre- and post- disk trouble and seen no changes where I didn't expect any (no obvious file corruption).
I have diffed the software and system registry hives pre- and post- disk trouble and seen no changes which seemed relevant.
I have created a new user account and cleaned up any environment variables in case environment was related. No change.
I did "sfc /scannow" and it found no integrity problems.
I tried "ngen update" to regenerate pre-compiled code in case I missed something that might be damaged and nothing changed.
I removed my virus scanner to see if it was interfering, no difference.
I tried running the test code in Safe Mode, same crash issue.
I assume I need to repair my .NET installation but because Windows 7 included .NET 3.5 - 2.0 you can't just re-run a .NET installer to redo it. I do not have access to the Windows disks to try to re-install Windows over itself (the computer has a recovery partition but it is unusable); also the drive uses a whole-disk encryption solution and re-installing would be difficult.
I absolutely do not want to start from scratch here and install a fresh Windows, reinstall dozens of software packages, try and remember dozens of development-related customizations/etc.
Given all that... does anyone have any helpful advice? I need .NET 3.5 - 2.0 working as I am a developer and need to build and test against it.
Thanks!
Quinxy

The short answer is that my System.ni.dll file was damaged, I replaced it and all is well.
The long answer might help someone else by way of its approach to the solution...
My problem related to .Net being damaged in such a way that apps wouldn't run except through a profiler. I downloaded the source for the SlimTune open source profiler, built it locally, and set a break point right before the call to Process.Start(). I then compared all the parameters involved in starting the app successfully through the profiler versus manually. The only meaningful difference I found was the addition of the .NET profile parameters added to the environment variables:
cor_enable_profiling=1
cor_profiler={38A7EA35-B221-425a-AD07-D058C581611D}
I then tried setting these in my own user's environment, and voila! Now any app I ran manually would work. (I had actually tried doing the same thing a few hours earlier but I used a GUID that was included in an example and which didn't point to a real profiler and apparently .NET knew I had given it a bogus GUID and didn't run in profiling mode.)
I now went back and began reading about just how a PE file is executed by CLR hoping to figure out why it mattered that my app was run with profiling enabled. I learned a lot but nothing which seemed to apply.
I did however remember that I should recheck the chkdsk log I kept listing the files that were damaged by the drive failure. After the failure I had turned all the listed file ids into file paths/names and I had replaced all the 100+ files I could from backup but sure enough when I went back now and looked I found a note that while I had replaced 4 or 5 .NET related files successfully there was one such file I wasn't able to replace because it was "in use". That file? System.ni.dll!!! I was now able to replace this file from backup and voila my .NET install is back to normal, apps work whether profiled or not.
The frustrating thing is that when this incident first occurred I fully expected the problem to relate to a damaged file, and specifically to a file called System.dll which housed the methods that failed. And so I diffed and rediffed all files named System.dll. But I did not realize at that time that System.ni.dll was a native compiled manifestation of System.dll (or somesuch). And because I had diffed and rediffed the .NET related directories and not noticed this (no idea how I missed it) I'd given up on that approach.
Anyway... long story short, it was a damaged System.ni.dll that caused my problems, one or more clusters within it had their content replaced with 0x0 and it just so happened to manifest as the odd problem I observed.

This sounds like a timing issue, which the profiler "fixed" by making it just a little slower.
Many profilers use instrumentation (more info here), which slightly slows down the application. Apparently it slows one thread down enough that another thread can do a little bit more work, preventing that crash. Errors like these often do not manifest themselves directly on the developers machine, but surface as soon as they run on a processors with more cores or hyper-threading. Sometimes they only occur in release builds (or vice-versa in debug builds). Timing issues can be difficult to track down since the same code may give different results in different conditions (in profiler or debugger).
From your description I'll attempt to do a wild guess on how it may be fixed:
Try to find in the source where the new threads are started. Then after they are spawned add a System.Threading.Thread.Sleep(500); line there to pause the main thread and give the new threads some time to start.
Without the source code and a few stack traces of the crashes, this is quite a bit of guesswork.

Difference between Visual Studio launching an executable and launching it yourself?

I work on an application in C# 4.0 (VS2010), and I have a very strange situation. A bug is reported to me from all the team and I always fail to reproduce it, till one of the other developers told me to double-click the executable and follow the bug's scenario instead of launching it from VS2010.
After some research, I found that most of the comments on this problem are regarding uninitialized heap memory and the like, but in a C++ context. I know that C# produces an error rather than a warning if a variable is left uninitialized, so this is not the problem, most probably.
Both builds are the same on my machine and the users', and I now know that pressing F5 (Start with debugging) doesn't produce the problem, while Ctrl+F5 does. So the question is not the difference between both (other questions have already addressed that), but rather: how can attaching a debugger to a C# process affect its behavior?!
The code creates a connection over the network.

So the question is: How can attaching a debugger to a C# process affect its behavior?!
In all kinds of ways. It affects JIT optimizations, garbage collection, timing (think race conditions), anything which explicitly tries to detect whether it's running in the debugger, and potentially the order and timing of type initialization.
If you can now reproduce it, I would start adding logging and see where that leads you - once you've worked out what the problem actually is, you may well find it's obvious why the debugger changes things.

App That Uses SDK BSODs in Delphi 2007 But Works in C# [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
I'm coding an application that uses a third party SDK (OCXs). I use the SDK in C# and it works just fine. However, I can create the simplest test application with the same objects from the SDK in Delphi 2007 and it compiles ok, but BSODs on the same machine when it gets to a certain point. I've run some other test applications that use the SDK and they operate correctly, so I know the SDK is installed ok and functioning properly.
Other Delphi projects I work on that don't use this specific SDK operate properly.
Any ideas on how to try to fix this problem? Might I need to remove the OCXs that I've installed in Delphi and add them back? How do you do that?

Very unusual problem. Windows NT based OS's are normally very good at containing faults that occur at Ring 3 inside of user applications. Does the SDK in question interact with hardware through kernel level drivers? Also, what information appears on screen when the system BSOD's. Sometimes this is a clue as to the nature of the problem (e.g. Interrupt handler reentrancy problems, faulty hardware, interrupt conflicts). I have seen this type of problem with Dialogic boards on occasion. The problem may also be a kernel level fault that is not driver related.
Without additional details it has hard to do more than speculate as to the cause. I am inclined to think this is not a FPU control word problem, but I could be wrong. FPU control word problems can result in exceptions, but the exception would need to occur in a critical execution context like a driver where it would not be caught and handled by the OS.
FWIW I have seen FPU control word problems in Delphi JNI libraries that crashed the JVM and host application. The fix was to explicitly wrap the call with code to change and restore the control word as suggested by NineBerry. This works provided the application is not multi-threaded.

It turns out this was caused by Kaspersky antivirus. I tracked it down by running Windbg against the crash dump and it pointed to kl1.dll. After searching around I tracked down this article which identified it as Kaspersky. I disabled Kaspersky and the BSOD no longer occurs.

There is a possibility that floating point exceptions cause the problem. Most runtime environments disable floating point exceptions, but with Delphi, they are enabled.
The disable floating point exceptions, use the following code:
Set8087CW($133f);
Note that this will change the behaviour of your own code as well. You will not get any exceptions any more, if there are errors in a floating point calculation, instead the result variable will be set to either NaN, Inf+ or Inf-.

Just because you can use the SDK fine from other applications doesn't inherently mean that it doesn't have a problem. It may be reacting badly to certain data items or even to items that shouldn't exist--assuming the contents of memory that doesn't formally contain anything.
I'm sure you've run into bugs caused by uninitialized data items that simply get whatever value was in memory, something like this could be going on with the data area in question being passed in. (Say, a padding byte in a record structure...)