I am trying to debug some code, as a class is throwing an exception when called.
The code is:
public TrackingStrategy1(string Name, RobotGeometry geometry)
{
trackSystem = new TrackSystem(geometry, Name);
}
which calls (In the same project):
public TrackSystem(RobotGeometry geometry, string Name)
{
finder = new FindModel(geometry); //breakpoint inserted here fails
finder.InitModel();
finder.useGPU = false;
}
I am getting the exception 'Method Not Found: TrackSystem.FindModel..ctor(RobotGeometry). However, a break point inserted at this point is not hit. If I comment out the new line, I get the same exception for the next line.
FindModel is referenced in another project contained in the solution, which I have re-referenced to several times, followed by a rebuild.
Why does Visual Studio not stop at breakpoints inserted in this constructor?
Before loading each class, Visual Studio was checking for the existence of all external dll method calls.
Because this occurs before the constructor is called, the break points in the constructor are never called.
In this case, the reason for failure was that 2 different projects were referencing different versions of FindModel - and the wrong one for this project was used in the build.
Related
I'm getting some extremely weird behavior. An object appears to be null and not null at the same time, and a statement is getting skipped. I'm probably being an idiot, but if it's my fault I don't see it. I'm building using Visual Studio 2008 on a Windows 7 SP1 OS.
public void ReadTrendData(OpcDriver opcDriver)
{
if (opcDriver != null)
{
int a = 1;
}
if (opcDriver == null)
{
Exception ex = new Exception("Null OPC driver received by ReadTrendData()");
throw ex;
}
The opcDriver object is successfully created and passed in to this method. When I step through, the "int a = 1" statement is executed. Then, in the next if block, execution gets to the "throw ex" statement without executing the line above that creates the ex object. So, ex is null and throwing null gives me an access violation exception.
Do you have any idea what could be happening here?
A couple of members of the OpcDriver class are instances of classes from a 15-year-old ungauranteed, unsupported sample library that uses COM to interface with an OPC (OLE for Process Control) program. The only thing I can think of is that somewhere in the bowels of that library something grotesque is happening, but I can't think how this can be possible.
Thank you.
You should try on newer visual studio build. I got almost the same problem on 2008 and 2012 versions. It's a visual studio compile time bug. You should check your build option, if you selected "release" mode you should check back to debug and try again.
To sum up, it probably the problem's root is wrong operator overloading (== and/or !=). The test
if (Object.ReferenceEquals(opcDriver, null))
works as expected.
I am building a library which contains a lot of wrappers for various bits of code I use a lot.
My library code:
public static void Create(string name, string location, List<string> commands)
{
if (!Directory.Exists(location))
{
throw new DirectoryNotFoundException();
}
else
{
File.WriteAllLines(Path.Combine(location, name), commands);
}
}
My sample app using the library
AwesomeFunction.Create("Foo", "C:\\DoesntExist\\Bar", new List<string> { "List of stuff" });
If the directory given isn't found it throws on the line throw new DirectoryNotFoundException(); which makes sense, but I need it to throw on the AwesomeFunction.Create function.
This will stop it switching to the library code if it throws, instead it will highlight the AwesomeFunction line in VS.
A comparable example would be throwing an exception on
Directory.Delete("C:\\DoesntExist\\Bar");
Where it will highlight that line, even though the throw is in the Directory class.
Any help appreciated.
EDIT
If I copy the library to a different location i.e. C:\mylibrary it still opens the source code for it, even though I didn't reference it through a project.
Another problem I found it that when I don't add it from my projects I don't see my XML comments on the functions.
Any ideas?
You could achieve that by using an assembly reference instead of a project reference for the library. This way you will not have the source code of the library in the consuming project and VS will break on the AwesomeFunction.Create function call. That's what happens when an exception is thrown inside the Directory.Delete call that you provided. Since you don't have the source code of this method linked in, VS simply stops on this line and not on the actual line inside this method that threw the exception. Obviously in the exception stacktrace you get the full stack of method calls and the origin of the exception.
I refactored my application a while ago and since then I've been having problems with debugging using Visual Studio 2010.
My application works as expected while not debugging (not stepping through the application. An attached debugger does not cause any issues). However, when a breakpoint is triggered and I start to step through the app, Visual Studio and the app both hang after at most 3-4 steps.
To emphasize this point even more: It works well with my customers and regardless of whether I start it from Visual Studio or stand-alone - as long as no break point is triggered.
It does not matter where in the code I place the break point.
IDE: Visual Studio 2010 x64
Platform: .NET 4.0
The refactoring included a lot of cross-thread calls to BeginInvoke - all channeled through the following method:
public static void BeginInvokeIfRequired(this Control control, Action action)
{
if (control.InvokeRequired)
{
control.BeginInvoke(action);
}
else
{
action.Invoke();
}
}
There is not a single call to Control.Invoke() in the project.
Is there something wrong with the above method?
Additionally, I'd appreciate any hints on how you would track down this bug. My current approach is to add output to the console and selectively deactivating parts of the code.
I would suspect that in some cases the code you show poses a problem since InvokeRequired lies in case IsHandleCreated is false - it returns false even if you are not on the GUI thread.
For reference see http://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokerequired.aspx .
The following code throws an exception instead of hanging... the fact that it "works as expected" when no breakpoint is hit might be a result of the debugger freezing all threads on hitting a breakpoint which in turn might lead to a different order of execution etc.
Altogether this means: you might have some "race condition" in your code where BeginInvokeIfRequired is called on a freshly created control before that control has a Handle. This can even be some 3rd-party code you use...
public static void BeginInvokeIfRequired(this Control control, Action action)
{
if (control.IsHandleCreated)
{
if (control.InvokeRequired)
{
control.BeginInvoke(action);
}
else
{
action.Invoke();
}
}
else {
// in this case InvokeRequired might lie !
throw new Exception ( "InvokeRequired is possibly wrong in this case" );
}
}
I've been messing with VS 2010 debugging settings, trying to get stepping into the .NET Framework working. Well, I can't get it to work. I've also tried the Reflector VS plugin and that was working at one point.
Then I randomly started getting this error:
This only happens when I have a breakpoint on a line that calls IEnumerable<T>.ToList(). If I try to step-over or step-into on that line where my breakpoint is set, I get this error dialog and my debugging session ends.
If I move the breakpoint to the line below, the debugger makes it past the ToList() call!
I've tried the following to no avail:
Removing the Reflector plugin.
Undoing my changes in the Tools > Options > Debugging window (unchecked the option to step into the .NET Framework; unchecked the source server option; checked the just my code option).
Unchecked Microsoft Source Server in the Tools > Options > Debugging > Symbols window.
Cleared the symbol cache.
What is going on?
Because this was the first place I came to when I searched for an answer, I'll add what I found out.
In my case, I had the debugger set up in the solution to start multiple projects. For some reason this setting was changed by Visual Studio so that no project was starting. Correcting the setting in the solution immediately solved the problem.
The problem was not difficult to solve, but the error message was more than a bit irritating.
I've just found this answer useful. All I did was change my start-up project to another, and back to normal.
My project probably lost this setting somewhere, and resetting it made it available again.
It was a ToString() override that make the debugger crash ! (After the evaluation the debugger will show you the result with the ToString() method). And if you get an exception in the ToString(), you will never catch an exception because you cannot code them on the debugger behaviour.
I've got this answer from msdn
I suffered from same problem....
I found one solution which heard uncommon....
The debugger cannot continue running the process.Process was terminated
While debugging your code step by step , you will find the line , from where error redirecting.
If you are using " ToString() " anywhere in that file ,please remove that .
Instead of the ,you can use Value / Text .
It works fine.
............
If you were not used ToString() any where in program , then reload project copy by removing completely.
I had the same problem. I traced it down to a class(step-by-step debugging) and finally to a property(commenting all the code, then step-by-step uncommenting).
this property returned a typed dataSet from a table.Dataset
private typedDataSet myDataSet
{
return this.DataSet as typedDataSet;
}
this was in a DataTable partial class.
After I removed this property everything went OK.
I ran into this issue with a code bug from copy/paste. Instead of get/setting the private member variable, I did a get/set on itself. When I referenced the property in other code the debugger terminated (2010):
public bool ProdToDeve
{
get { return ProdToDeve; } // <= missing underbar
set { ProdToDeve = value; }
}
private bool _ProdToDeve = false;
This message will also show up when you're trying to debug a Xamarin solution but you have a class library selected as the startup project instead of your application porject.
It occurred to me when I was doing the following:
throw new Exception(timeout.TotalSeconds + " second(s)");
That's because timeout.TotalSeconds.ToString() which indeed is an override method for an object of type double, was throwing a Parameter not valid exception.
Finally, for safety I ended up doing the following:
throw new Exception(System.Convert.ToString(timeout.TotalSeconds));
Well, typically, this is also the kind of error message you can get in a multi-threads context. In brief, it involves concurrency : make sure that your resource accesses are always secured.
In my case, I got this error message when I forgot to secure resource accesses at some places within my code. To solve this issue, I just had to decorate the critical sections with a lock instruction (on the concerned resource). I hope this will help those who are in this context.
This application has a WCF web service that is called by a WinForms app. The WinForms app has a class WCFCache to manage data from the service. There is a section like this in that class to manage an optional custom configuration section that a subset of the machines have:
private bool? m_HasCustomConfiguration = null;
public bool HasCustomConfiguration
{
get
{
if (m_HasCustomConfiguration == null)
m_HasCustomConfiguration = (CustomConfiguration != null);
return (bool)m_HasCustomConfiguration;
}
}
private WCFService.CustomConfiguration m_CustomConfiguration = null;
public WCFService.CustomConfiguration CustomConfiguration
{
get
{
if (m_CustomConfiguration == null)
{
if (m_HasCustomConfiguration.HasValue
&& !m_HasCustomConfiguration.Value)
return null;
try
{
using (WCFService.WCFServiceClient wcf = new WCFService.WCFServiceClient())
{
m_CustomConfiguration =
wcf.GetCustomConfiguration(Machine.ProcessID);
// Above method returns null if no record exists.
m_HasCustomConfiguration = (m_CustomConfiguration != null);
}
} catch (Exception e) {
// Error logging & re-throw
}
}
return m_CustomConfiguration;
}
}
When I step through the debugger in code that calls either of the above properties like this:
if (!Program.WCFCache.HasCustomConfiguration)
return new List<CustomComponents>();
...it throws the following exception:
System.AccessViolationException was unhandled
Message="Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
Source="System.Windows.Forms"
...
When I step onto the line containing the reference, there is a long pause, followed by a VS popup with the exception.
The exception doesn't appear when I just put a breakpoint after the above code has executed. It doesn't even appear when I put a breakpoint inside the accessors of the properties. It only occurs when I step onto a line with one of those properties from the outside. (So there is a workaround, but it can be a pain.)
Why is this happening? Can I stop it?
Edit: The whole application was written in the last year in 3.5 C#/.NET with WCF communicating between components; meaning, we don't have legacy unmanaged DLLs. Just two unmanaged calls: one to advapi32.dll when the WinForms app is loading, in the username detection procedure. The issue I'm having happens only in this one place in the code, in a place that is about as unrelated to the login section as you can get. The other is to kernel32.dll, in a GC force-flush long after anything is done with the results from calls like the one above.
Are you using any P/Invoke or other such native code? Odds are, that's where you should start looking.
This exception is a symptom of a larger problem, namely memory corruption (that what the exception says, after all). If this was a native application, you'd get a crash.
So, look at any native calls, make sure they're operating correctly, maybe run them under a debugger to try and trap the error closer to home.
Sorry, can't really give better advice given the circumstances.
I eventually found that others have encountered this situation and that it is likely a Visual Studio bug. I was using VS 2008 when the problem occurred.