What is this little blue arrow about?
It freezes execution of my ASP.NET program when I do not want it to (note the disabled breakpoint).
Any resources or clarification around what this little guy represents would be much appreciated.
You may have a Debugger.Break(); command on the function or code called on that line. Check this post for more info.
EDIT
Answer by #Thomas:
This line of code is currently executing, it calls something else,
e.g. native code or .NET internal code and an exception happens there.
You can see both arrows in the call stack window:
Perhaps you need to turn on "Show external code".
If you can't see the exception dialog, usually you can show it like
this:
Showing Exception in VS
Related
When I start a debug session, program execution halts at a line that appears to be breakpoint (yellow background color). I must press F5 to continue, and the program proceeds normally.
I call it a phantom breakpoint because no breakpoint appears to be set, and even though executions stops within a loop, I need only press F5 once to proceed.
I tried setting a breakpoint at the phantom location, and removing all breakpoints but to no avail.
The only other similar problems I can find are for Java, and MS-Access where the solution was to de-compile the application.
Although this is very annoying while in development, I was gritting my teeth and baring it until the application was installed on a Citrix server where an error message box is displayed saying that a breakpoint had been encountered.
As an afterthought, I just rebuilt the setup program and after running the application, a critical error was issued. In debug mode, the message was "myapp.exe has triggered a breakpoint:". I cannot explain why it works at all on the Citrix server).
I sure would appreciate any suggestions on how to resolve this issue.
TIA
You are running somebody else's code and that code has an explicit debugger break instruction compiled into the program. You can do so for example by writing Debugger.Break() in a managed program. It could also exist in unmanaged code, the __debugbreak() intrinsic or the DebugBreak() winapi function do this. Could be a simple oversight, it could be that it was intentionally left in the code to warn about a problem.
One way to find the programmer that did this is by using the debugger. Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" option. Then Tools + Options, Debugging, General, untick the "Enable Just My Code" option.
Run the program and reproduce the condition. Now use Debug + Windows + Call Stack and look at the very top of the list. Scroll up if necessary. It might well be grayed out to indicate that this is not your code, it won't be. You'll see the name of a DLL there. Call the company or programmer that wrote that DLL and ask for advice.
I'm developing a Metro-style app (for Windows 8) using C# and XAML. I have set up my viewmodels to be used as design-time datacontexts, like so:
xmlns:vm="using:hub.ViewModels"
d:DataContext="{d:DesignInstance IsDesignTimeCreatable=True, Type=vm:ViewModels
My app appears to work perfectly when run, but in the design views of both VS 2012 and Blend, I occasionally get this (unhelpful) error message:
An Exception was thrown. TargetException: Error in the application.
Stacktrace
at System.ComponentModel.PropertyChangedEventHandler.Invoke(Object sender, PropertyChangedEventArgs e)
InnerException: None
This only happens in the design view - meaning I can't set breakpoints around all my INotifyPropertyChanged() events.
What is the best approach to debugging design-time errors?
If this happens consistently or semi-consistently, you can attach the debugger to the XAML designer:
Start Visual Studio; open your project and open a XAML file, causing the XAML designer to load
Start a second instance of Visual Studio. Open your project but make sure no XAML documents are open.
Ensure that Just My Code is disabled: From the Tools menu, select Options. Select the Debugging category. In the General page, ensure the check box next to Enable Just My Code is unchecked.
From the Debug menu, select Exceptions... and check the Thrown check box next to Common Language Runtime Exceptions. This will enable first chance handling of all CLR exceptions. If you know the specific type of the exception, you can enable first chance handling for just that type.
From the Debug menu, select Attach to Process. In the Attach to: field, click Select... and check the Managed (v4.5, v4.0) entry in the list and click OK.
This is necessary because the debugger may misdetect the process as a native process if it attaches while the process is executing native code. If your project contains native code, you'll want to check the Native check box in the list as well (you can debug both managed and native code at the same time).
In the Available Processes list box, find the xdesproc.exe that corresponds to your project and click Attach.
If there are multiple processes (usually because you have multiple projects open or because the designer is reloading or has recently reloaded), it can be difficult to determine which designer process belongs to which Visual Studio instance. It's often easiest just to attach to all of them. A tool like Process Explorer can help you figure out which designer process belongs to which instance of Visual Studio.
Note: Do not attach the debugger to a designer process (xdesproc) that belongs to the same instance of Visual Studio that you are using for debugging: doing so is likely to cause Visual Studio to hang. You must always use two different instances of Visual Studio.
Do whatever you need to do to repro the bug. When it occurs, the debugger will break at the point where the exception is thrown. The debugger should load the symbols for your assemblies.
I got here while looking for info on how to debug designer time instance problems, though I did not have the same problem as rikkit. But...I'm sharing the solution to a related issue just in case others having the same problem reach here as well:
Make sure you have the "Enable/Disable Project Code" toggle set to "enabled"...in VS/Blend 2015 it's a small icon below the XAML editor
as shown here.
If it's disabled, this could be the reason your design time instance doesn't seem to be working.
Further, if it's disabled and you attempt to debug using a second VS instance, then when you attach to the XDesProc any breakpoints you set in the code-behind will report that they "will not currently be hit. [because] No symbols have been loaded for this document".
You might think that you need to somehow load the symbols, but if you open up the Modules window attempting to do so, you won't even see your module in the listing.
I lost a couple hours on this issue because of this setting being disabled. Hope this helps others not do the same.
I'm not sure about it but I believe you can check for the IsInDesignModeProperty Field. I remeber having to do so on WinForms sometimes.
Also take a look at this link Troubleshooting WPF Designer Load Failures
I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?
My application shows this error
asm CPSqliteConnectionStatementForSQL 0x30897lb3:10
and it stopped at this breakpoint in debugger
0x308971cb <+0024> mov 0x8(%edi),%eax
Does someone know about it?
The assembly code won't tell most of us anything at all, and your question is pretty light on detail about the context in which the problem occurs, such as what your app is trying to do when it crashes, whether this is always reproducible, etc. If you post more information we'll be able to help you more.
If you're debugging in Xcode, trace back up the call stack until you reach your code, then set a breakpoint there and debug your program again. When it stops at that point, try examining the related variables and see if they have the values you expect.
Edit: At the request of the asker, here is a slight clarification. When it stops at a breakpoint, the Xcode debugger window will look something like this: (from this section of Apple's Xcode Debugging Guide)
http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeDebugging/art/debugger_disassembly.jpg
The stack frames are shown in the upper-left rectangle, and you can click on a row in the table to jump to that point in the code. Grayed-out lines are those that do not have viewable source code available. Scroll down until you see a line with black text and click on it. This will show you the point at which execution left your code and entered third-party code, and you can then examine variables to get a better idea about what the problem may be. If you have further questions, I highly recommend reading through the debugging guide linked above.