So I have a weird situation, where I get to an if statement while debugging, and I'm finding that even though EM=="M", my if statement if(EM=="E") is being entered anyway... I'm also noticing that some of my code seems to be just getting skipped over when I'm stepping though the code(F11).
I'm using C# in VS2015 and VS2017, it's having the issue in both versions. I was using Framework 4.5, I had switched it to 4.6.1 to build a compatible version for a different program. But switching that back didn't change anything...
public static string EM = "";
Database db = doc.Database;
//db.measureunits is 0 or 1
if (db.measureunits == 1) // english
{
EM = "E";
}
else // metric
{
EM = "M";
}
try
{
if (EM == "E") //If english
{ <-- Breakpoint STOPS Here EM is equal to "M" at this point, which shouldn't allow the break point to be hit, since EM("M")!="E"
topText.TextString = rad + "\" minimum bend radius";
}
if (EM == "M") //Metric
{ <-- Breakpoint never stops Here
topText.TextString = Convert.ToString(Math.Round((Convert.ToDouble(rad)) * 0.3048, 2)) + "\" minimum bend radius";
}
}
catch (IOException e)
{
// Extract some information from this exception, and then
// throw it to the parent method.
if (e.Source != null)
System.Windows.Forms.MessageBox.Show($"IOException source: {0}", e.Source);
throw;
}
If anyone else is aware of this issue or know's what I may be doing wrong, help would be appreciated.
The following workaround might be helpful
Delete bin and obj folder then re-build.
Restart Visual Studio OR PC
A few ideas.
There occures an exception so that it jumps over the code which is coming after. Press Ctrl + Alt + E and check "Common Language Runtime Exceptions". Now it should stop at the moment an exception occures and show it to you.
Your code was optimized during build. Try to build in debug mode or uncheck "optimize code" in the project properties under "Build".
Delete the obj and bin folders. You already tried this.
There is something fishy with the PDB file. The PDB file contains information for the debugger. Project properties -> build -> advanced => set "Debug Info:" to "full" (if you use debug configuration this should already be the case) and rebuild the whole solution.
Related
I did find a few similar questions, but they weren't able to point me in the right direction... This may be something entirely stupid, but if anyone could tell me why I can't get a string populated I'd appreciate it. Here's my method that's failing:
private static string passwordTrace { get; set; }
// ... lots of other code
private static void RefreshPassword()
{
try
{
string filePath = "\\\\[server ip]\\share\\folder\\file.abcd";
string npDecrypted;
DateTime lastRefreshDate = Properties.Settings.Default.lastRefresh;
if (DateTime.Now >= lastRefreshDate.AddDays(30))
{
using (StreamReader sr = new StreamReader(filePath))
{
string npEncrypted = sr.ReadLine();
if (npEncrypted.Length != 24)
{
string fr = File.ReadAllText(filePath);
npEncrypted = fr.Substring(0, 24);
}
npDecrypted = Decryptor(npEncrypted);
passwordTrace = npDecrypted; // added for debugging only! remove when done.
secureString npSecure = new SecureString();
foreach (char c in npDecrypted)
{
npSecure.AppendChar(c)
}
Properties.Settings.Default.adminpw = npSecure;
Properties.Settings.Default.Save();
}
}
}
catch (FileNotFoundException fnfe)
{
// code for handling this type of exception
}
catch (NullReferenceException nre)
{
// code for handling this type of exception
}
catch (Exception e)
{
// code to catch ANY other type of exception
}
}
Now, there are no errors or warnings when the VS debugger compiles everything, and it works correctly when debugging. But, if I copy the compiled exe (from C:\project\bin\Debug directory) and run it the issue arises.
The point that says passwordTrace = ... is called at another point by a message box. This works correctly when running via debugger and there aren't any exceptions thrown anywhere (I do have try/catches all over the place), but for whatever reason the PasswordTrace and the Properties.Settings.Default.adminpw don't seem to be holding their value throughout the applications execution.
Also, the file that is being read is an encrypted text file which will always have only 1 line of characters and that line is always 24 characters long. An example would be:
09sdjf09ausd08uf9!%38==
As a final statement, I also copied the app.exe.config and app.pdb to the server directory where I copied the compiled .exe file to see if that had anything to do with it and it didn't fix anything. I also tried running the .exe directly from the Debug directory (the same file that I'm copying elsewhere) and it works correctly. As soon as I move it off of the Local Disk it doesn't work.
So, my suspicions are that it has something to do with the environments working directory, or something to do with how the app is executing. I read something somewhere that noted the default users is not set, but I think that was specifically regarding ASP.NET. If that was the case and the user double-clicking on the .exe didn't have a proper network authentication then what would I do? And if it has something to do with the working directory, how can I circumvent this?
I'm gonna keep fiddling and if I figure it out I'll update this, but I'm so lost at the moment! lol! And for the last time - everything it/was working correctly until copying it to the server location.
Thanks in advance! :)
I have some Emgu code that was working in both debug and release builds. Somewhere along the way, it quit working, but I was deep into adding something else so I didn't pursue it at the time.
When I did finally getting around to trying to fix it, I find that a release build works, but not a debug build. Between the time it was working, and not, I did not change any references or referenced DLLs. I spent some time investigating that anyhow as I had read somewhere that open CV has some trouble debug vs release somewhere, but never found anything.
I just applied the last version of Emgu, and the same problem exists; works perfect in release, not at all in debug.
The relevant code snippet is;
var filteredFrame =
channels[0].SmoothGaussian(VisionData.SmoothGaussians)
.Erode(VisionData.Erodes)
.Dilate(VisionData.Dialates);
using (MemStorage stor = new MemStorage())
for (
Contour<System.Drawing.Point> contour =
filteredFrame.FindContours(Emgu.CV.CvEnum.CHAIN_APPROX_METHOD.CV_CHAIN_APPROX_SIMPLE,
Emgu.CV.CvEnum.RETR_TYPE.CV_RETR_EXTERNAL, stor);
contour != null;
contour = contour.HNext)
if ((contour.Area > (VisionData.ContourMinArea * VisionData.ContourMinArea))
&& (contour.Area < (VisionData.ContourMaxArea * VisionData.ContourMaxArea)))
CurrentFrame.Draw(contour.GetMinAreaRect(), RectBrush, 2);
d.InvokeAsync(() =>
{
DataModel.CameraImageSource = Emgu.CV.WPF.BitmapSourceConvert.ToBitmapSource(CurrentFrame);
DataModel.FilteredImageSource = Emgu.CV.WPF.BitmapSourceConvert.ToBitmapSource(filteredFrame);
});
The input filtered frame(image) looks identical in both debug and release.
I'm using Unity (3.4) Monodevelop (2.4.2) and it's not executing the code properly when I step through it in the debugger. Here's a link to the video that shows it, please run it at 720p and fullscreen it...
http://www.youtube.com/watch?v=LGN7kxMUqjA
Also, here are some screenshots showing the debugger displaying really strange values when I mouseover a variable. Here's what it looks like when it correctly shows the value of the xSectionPixel in the first if block...
And here's what it looks like when it incorrectly shows the value of the xSectionPixel in the second if block...
This is also the line of code where it starts executing code incorrectly.
What would cause this?
I've tried reinstalling the tools, using a fresh copy of the code from the repository, I even set it all up on a different computer with a different OS (Win 7) and it always does the same thing. Doesn't that mean it has to be my code then?
It's also worth noting that I'm using SVN to push/pull the code from a repository and my local copy exists in my Dropbox folder.
Thanks so much in advance for your wisdom! Here's the code as well if you can spot anything that might be breaking things (i.e. the way I'm using floats and ints maybe?)
Vector2 textureCoordToHexGridCoord(int textX, int textY)
{
Vector2 hexGridCoord = new Vector2();
float m = hexH / hexR;
int xsection = (int)(textX / (hexH + hexS));
int ysection = (int)(textY / (2 * hexR));
int xSectionPixel = (int)(textX - xsection * (hexH + hexS));
int ySectionPixel = (int)(textY - ysection * (2 * hexR));
//A Section
if(xsection % 2 == 0)
{
hexGridCoord.x = xsection;
hexGridCoord.y = ysection;
if(xSectionPixel < (hexH - ySectionPixel * m))
{
hexGridCoord.x--;
hexGridCoord.y--;
}
if(xSectionPixel < (-hexH + ySectionPixel * m))
{
hexGridCoord.x--;
}
}
//B Section
else
{
if(xSectionPixel >= hexR)
{
if(ySectionPixel < (2 * hexH - xSectionPixel * m))
{
hexGridCoord.x = xsection - 1;
hexGridCoord.y = ysection - 1;
}
else
{
hexGridCoord.x = xsection;
//hexGridCoord.y = ysection;
hexGridCoord.y = ysection - 1;
}
}
if(xSectionPixel < hexR)
{
if(ySectionPixel < (xSectionPixel * m))
{
hexGridCoord.x = xsection;
//hexGridCoord.y = ysection - 1;
hexGridCoord.y = ysection;
}
else
{
hexGridCoord.x = xsection - 1;
hexGridCoord.y = ysection;
}
}
}
return hexGridCoord;
}
I have no specific experience with the frameworks you use, but I do have a lot of experience with debuggers.
The debugger behavior you see can happen in one of two scenarios (that I can think of...)
The symbol files and executing code are not synchronized with your source code, usually the IDE should detect that, but it some cases it doesn't, the solution is to delete all binaries, recompile and try again.
A bug in the debugger or the debugger extension (used to debug in the specific environment your are in, i.e. unity/monodevelop).
If you are unable to resolve it, I would add logging to your code and use it to really understand what happens.
I saw similar behavior on MonoDevelop with WinForms applications, solved with reinstalling debugger.
Have you tried that or using Visual Studio to verify that the problem is in the code?
Do you have optimizations turned on? If so, does disabling them make stepping any less erratic?
Enabling optimizations is one thing I can think of that no one else has mentioned yet that could potentially cause what you are seeing.
Can you try removing you breakpoints, setting a new one, and stepping through the code?
The reason I ask is there are ways that you can set values using breakpoints. A very similar thing happened to me and was convinced that there was a compiler bug. After stepping through the CLR and number of other things with no answer, we stumbled across a breakpoint that was set earlier for testing, and never removed.
That kind of behavior usually happens to me when I'm debugging a multithreaded part of an application.
What happens is that while you debug several threads at once, the debugger in visual studio keeps switching between them without notifying you by default.
Now since threads are not executing the same lines at the same time, you got unexpected "jumps".
I believe it is widely used in game developpement, so in your case you got two choices:
1) Make only one thread run while you make your debugging.
2) Make unit tests <= That's the "best practice".
You can start by having a look at NUnit
The first issue most likely has something to do with the sequence points in the JITed code. These are the points where the debugger can stop. They're computed by the runtime based on the IL and debug symbols generated by the compiler, therefore this is most likely a runtime or compiler bug. I don't know what version of the Mono runtime and compiler is being used by Unity, but it's quite that this has been fixed in a newer version. If you can reproduce this using a "normal" console app using the latest official MonoDevelop and Mono 2.10.x, please file a bug at http://bugzilla.xamarin.com with a test case. If not, please ask Unity to upgrade their version of Mono.
The second issue looks like an issue in MonoDevelop's expression resolver that's used to resolve the symbol under the mouse. This may have been fixed in a newer version of MonoDevelop - likewise, please try to repro with the official MonoDevelop 2.8.4, and file a bug if it's still an issue.
I've been trying to track down why my Office2010 plugin leaves a null pointer exception during uninstall and the 2007 version does not. (Edit: 2007 is at same state as 2010 - FAIL)
To narrow it down I have put in a couple of eventlog traps, meaning if code reaches this point - I should get something in the Eventlog. No such luck. Now either I written the eventlog trap wrong or code doesn't reach that point.
In the CustomSetupActions - ClickOnceInstaller.cs
public void Uninstall(System.Collections.IDictionary savedState)
{
// write something to eventlog
// This is not being fired, the exception doesn't reach here or writing to eventlog fails.
if (!EventLog.SourceExists("OfficePlugin"))
{
EventLog.CreateEventSource("OfficePlugin", "Application");
}
EventLog.WriteEntry
("OfficePlugin"
, string.Format("Uninstalling: (bug hunting)"), EventLogEntryType.Information);
string deploymentLocation = (string)savedState["deploymentLocation"];
if (deploymentLocation != null)
{
string arguments = String.Format(
"/S /U \"{0}\"", deploymentLocation);
ExecuteVSTOInstaller(arguments);
}
}
As for the ExecuteVSTOInstaller(string arguments)
2007 refers to: string subPath = #"Microsoft Shared\VSTO\9.0\VSTOInstaller.exe";
2010 refers to: string subPath = #"Microsoft Shared\VSTO\10.0\VSTOInstaller.exe";
If the first trap had fired, this is where I would have placed the trap afterwards.
--
I have another method that handles the registration db
RegisterOffice2010AddIn.cs
public void UnRegisterAddIn(string applicationName, string addInName)
{
Next line is precisely the same eventlog trap as I just used/shown.
Difference between the two (2007 vs 2010).
private const string UserSettingsLocation =
#"Software\Microsoft\Office\12.0\User Settings";
vs
private const string UserSettingsLocation =
#"Software\Microsoft\Office\14.0\User Settings";
I can't think of any other place that might be interesting to place the trap. I have a CustomInstaller which doesn't do anything besides Dispose(bool disposing) and InitializeComponent()
Development:
Action start 14:21:00: PublishFeatures.
Action ended 14:21:00: PublishFeatures. Return value 1.
Action start 14:21:00: PublishProduct.
Action ended 14:21:00: PublishProduct. Return value 1.
Action start 14:21:00: InstallExecute.
MSI (c) (B8:BC) [14:21:01:013]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1001. Error 1001. An exception occurred while uninstalling. This exception will be ignored and the uninstall will continue. However, the application might not be fully uninstalled after the uninstall is complete. --> Object reference not set to an instance of an object.
DEBUG: Error 2769: Custom Action _EE8A0D36_BE55_421F_9A55_95470C001D87.uninstall did not close 1 MSIHANDLEs.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: _EE8A0D36_BE55_421F_9A55_95470C001D87.uninstall, 1,
Action ended 14:21:05: InstallExecute. Return value 3.
Action ended 14:21:06: INSTALL. Return value 3.
Googling the Error 2769 - gives an answer of "[TARGETDIR]\" , but I dont reference TargetDir, I reference deploymentLocation. And Yes I have tried adding the "\" to places I could think of. Including the setup - Registry - HKLM\Software\MS\Office\12.0\ ...etc... \Addins\Excel/Word/Outlook and the Manifest keyvalue. Gave no feedback, good or bad, errors or otherwise. I'm at a loss what else to try to hunt this one down.
I have a guess it is referencing to this, in the VDPROJ:
{
"Name" = "8:UnregisterOutlookAddIn"
"Condition" = "8:"
"Object" = "8:_73E71A44EB72485AB7367745F7D57F49"
"FileType" = "3:1"
"InstallAction" = "3:4"
"Arguments" = "8:"
"EntryPoint" = "8:"
"Sequence" = "3:3"
"Identifier" = "8:_EE8A0D36_BE55_421F_9A55_95470C001D87"
"InstallerClass" = "11:TRUE"
"CustomActionData" = "8:/addinName=\"OUR.Outlook.Outlook2010AddIn\" /application=\"Outlook\""
}
I found it throws two exception - the secondary under CustomSetupActions and UnregisterAddIn and the primary under ClickOnceInstaller and Uninstall. Howcome I mention them as 2ndary and primary. Well it will do the exception in CustomAction and then the killing one in ClickOnce. I've eliminated the one in CustomActions and I now only have to worry about the ClickOnce. From what I can gather the ClickOnce implements the interface specified in the Setup Project (Install, Rollback, Commit, Uninstall). I only have to figure out how it can run amiss the Uninstall method.
Disclaimer: Unless ofcourse I'm mistaken and is barking up the wrong tree.
Change to WiX. It became a workaround as the original is still true.
I have a Visual Studio 2010 solution consisting of 2 projects:
Core, a C# class library project which handles the functionality and data access
UI, an ASP.NET 4 website (.NET Framework 4) that references the Core, and calls functionality in the Core.
My exception handler is set in Global.asax (Application_Error.)
When an exception occurs in the UI, everything works perfectly, I get filename, line number, etc.
This is not the case for exceptions that occur in the Core.
For this, I get a stacktrace like:
{FillUserCount at offset 2376 in file:line:column <filename unknown>:0:0}
P.S. The Core.dll and Core.pdb are present in the UI Bin folder.
In Visual Studio -> Tools -> Options -> Debugging -> "Enable just my code" is unchecked and "Enable source server support" is checked.
Is there a way to get stackframe info (filename, class, method, line number) also for errors that occured in my referenced project ?
The solution to get this working was to create a new web site and re-referencing the Core project.
Still, the prerequisites that Jon Skeet mentioned remain the same:
the projects have to be built in Debug configuration, and not Release
while referencing a project, make sure PDB files are copied
on code side, when retrieving info about the exception that occured, and using StackTrace, make sure you create the instance with the second parameter set to true (true to capture the file name, line number, and column number; otherwise, false.)
This is my final working code. It may help others:
Exception ex = Server.GetLastError().GetBaseException();
StackTrace trace = new StackTrace(ex, true);
if (trace.FrameCount == 0)
return;
StackFrame stackFrame = trace.GetFrame(0);
string className, fileName, functionName, message;
int line = 0;
// if for some reason, filename is being retrieved as null
if (stackFrame.GetFileName() == null)
{
className = ex.TargetSite.ReflectedType.Name;
fileName = ex.TargetSite.ReflectedType.Name;
functionName = ex.TargetSite.Name;
message = ex.Message;
}
else
{
// Collect data where exception occured
string[] splitFile = stackFrame.GetFileName().Split('\\');
className = splitFile[splitFile.Length - 1];
fileName = stackFrame.GetFileName();
functionName = stackFrame.GetMethod().Name;
message = ex.Message;
line = stackFrame.GetFileLineNumber();
}
How are you referencing Core? If you've added a reference to the "Release" DLL, that would explain it... if you've just added a reference to the project and you're running a build with the "Debug" configuration then it should be okay.