Debug assertion does not prompt in IIS 7 - visual-studio

since moving to Windows 7 (IIS 7.5), the debug assertions do not prompt a pop up dialog anymore.
I have tested this in a separate project, and noticed that they do work when using the integrated Visual Studio Developer server (Cassini) but they do not work when using IIS Web Server.
This is a big issue for us since we are counting on debug assertions to identify potential programming errors, so any help would be appreciated.
Thanks. Eyal.

That's because failed debug assertions are displayed in the Output window now instead, under the Debug section.
To view the Output window in Visual Studio 2008 go to the 'View' menu and click 'Output'.
I also find it inconvenient. Some more info...

You can work around by using
System.Diagnostics.Debugger.Launch();
You can make for example this function
[Conditional("DEBUG")]
public static void AssertEx(bool condition, string message)
{
if (condition) return;
System.Diagnostics.Debugger.Launch();
// Still write the message on output
Debug.Fail(message);
}
and get similar results.

That is the default behavior now and it cannot be changed.
What you can is generate a file with the assertions that failed in your app. That will still help you track your issues without halting the app when running inside the IIS.
Take a look at this good article about it.

Related

Visual Studio - disable stepping into source code of module (Shouldly)

I am using a an assertion framework called Shouldly for C#.
The code looks like this:
[Fact]
public void SimpleTest()
{
false.ShouldBe(true);
}
This is the same as:
[Fact]
public void SimpleTest()
{
Assert.True(false);
}
However, when I debug the example that uses Shouldly, this happens:
But I want this to happen:
The issue
When I debug with Shouldly, Visual Studio steps into the source code of the Shouldly package. I don't want to see the internals, I just want to see what line of the test my code broke on. I can use the Stack Trace to find what line my code broke on but this slows down my flow a lot.
I remember when I first started debugging with Shouldly, VS asked me if it should download the source files (.pdb?) of Shouldly to debug with, I think I accidentally told it yes.
If I look at the Modules I have loaded in VS, it shows me this:
It thinks Shouldly is "User Code" which is probably why it debugs into this. How can I disable this?
I have this issue every time I change VS version. I've managed to fix it before but this time I can't figure it out.
You can disable symbol loading for a loaded module by:
opening the Module window
searching for the module you want to change
right clicking on it and disabling Always Load Automatically

Standalone IntelliTrace collected recording shows only external code

I am testing the standalone IntelliTrace recorder tool but struggle to use it for post-mortem debugging of a client WPF application.
I managed to record the data using the IntelliTrace recorder. However, when I view the created .itrace file in Visual Studio 2017 15.8.6 Enterprise, I cannot see any references to the code. VS tells me for all events that all threads execute only external or framework code.
The events that have been recorded are mostly WPF button click gestures. Even though the button click method itself is in BCL libraries, I was expecting to see click handler code. Furthermore, I also added a line to throw an exception in my app (which then of course is thrown in the code of the application), but for this, I also cannot see any code.
The collection plan did not make any difference. I was using the builtin ASP.NET Trace collection plan as it is supposed to be verbose, the default plan and a customized plan where I removed everything that is not important for the app under test.
The program database files are located next to the executables as I was executing the program from in its build output directory, so VS should not have any problems finding the pdbs.
The commandline I was using to start the collection is
C:\IntelliTrace\IntelliTraceSC.exe launch /cp:C:\IntelliTrace\collection_plan.ASP.NET.trace.xml /f:C:\IntelliTrace\test.itrace MyApp.exe
Am I missing something? What is required to see the actual code? Currently, I only see the sequence of events, which alone is pretty useless for debugging.
I am using the IntelliTrace collector version 14.0.24720.00.
You have to check your debbuger.
Try Right click on the project and under Configuration Properties -> Debugging there should be a row with Debugger type).
Can you try debugging with the type switched to mixed mode? It seems like you also have managed code running and it may be using the incorrect debugger if it is set to auto.
Are you still getting the same issue?
Also can you try debugging with Just My Code turned off. Tools -> Optio -> Debugging. Make sure Enabled Just My Code is unchecked. Does this issue still appear?
Also, try with:
Debug > Options > General > Uncheck "Enable Just My Code"
All the references that I mention has background in:
https://msdn.microsoft.com/de-de/library/dd264915(v=vs.120)
Hope it fix your issue

Debug a process that terminates after start

I need to debug a process (starting from an external exe) that terminates immediately after start, so I don't have time to attach. How can I debug it?
UPD I don't have source code of that external exe; I can decompile it, but it's impossible to compile it back
You need to launch your process for debug in a suspended state. Visual Studio is capable of that, just invoke the debugger like this:
devenv /debugexe yourprog.exe <arguments>
The process will start suspended so you'll be able to iterate through first instructions before the crash.
See the detailed answer here.
You just need to open Visual Studio, go to File -> Open -> Project / Solution
and select the exe.
Press F5 and you will see the exception in the Output window. If you go to the Debug -> Exceptions window and select everything you will see the first chance exception before it shutdowns the application.
Note that you don't need the source code at all to do this.
Hope it helps.
You need to start it with the debugger. This will start the program with the debugger already attached.
If you cannot do that with Visual Studio, you can use the Windows Debugging Tools, part of the Windows Driver Kit. Note that the linked kit is for Windows 8.1, you may need to find older versions if you're not on Windows 8.
You can enable debug mode runtime by placing some piece of code.
write a method as below:
[Conditional("DEBUG_SERVICE")]
private static void DebugMode()
{
Debugger.Break();
}
and call this method where you want to start debugging, for example in the OnStart event.
you have to build your code with debug mode. dont forget to remove this piece of code after debugging and want to release.

How to debug in VS instead of JIT Debugger?

UPDATE: navigating to the process via menu:DEBUG / Attach Process / iexplore.exe shows "Automatic: Silverlight code". i.e. VS 2010 already attached to the process. Why doesn't it go to debug view?
I have a frustrating debug behaviour going on on my laptop which I'd like to fix. I was following along with the demo called Silverlight TV 46: What's Wrong with my WCF Service?
On my computer, I noticed that putting throw new ArithmeticException() in the RIA service causes the just-in-time debugger to get involved (a bad thing -- I want VS). I can put a break point on the the throw new ArithmeticExpression() line, and VS stops as it normally does. Press F10, and I still get the just-in-time debugger kicking in.
On Yvor's computer (the presenter in the Ch 8 link above), the visual studio debugger kicks in instead of the just-in-time one. What am I doing wrong? Could having Redgate Reflector installed previously have caused this (it is gone now).
ERROR:
Visual Studio Just-In-Time Debugger
Code: 4004
Category: ManagedRuntimeError
Message: System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid.
Check ...
Possible Debuggers:
New instance of MS VS 2010,
New instance of VS 2008.
[checked] Set currently selected debugger as the default.
[unchecked] Manually choose the debugging engines
Action: Hit Yes.
2nd ERROR:
Unable to attach to the crashing process. A debugger is already attached.
I've spent several hours looking for a way to solve this.
Browser is IE9 / Silverlight 4.
Previously, I started starting the silverlight app directly via the VS2010 environment... but then decided to get more deployment compliant (again).
http://msdn.microsoft.com/en-us/library/cc838267(VS.95).aspx
Down the bottom they mention repairing from control panel / VS2010. Did that. Waited for ages, made coffee, did something else. Finally complete. Problem sill there. Included this step just-in-case the fix is cumulative (you get superstitious after a while with these things).
I then deleted zap files, switched startup page from html to the aspx one. Wired aspx to the xap (it wasn't pointing to the /debug/ folder). [note: looks like you can remove the debug via Silverlight Project / build / Output path: Replace Bin\Debug\ with Bin. With Silverlight I feel that the relative Uri path should match up to your html / aspx files no matter what -- wheather you are in Debug or Release.
project properties / Web / Specific Page
debugging works again!
Did .html stop debugging? Casual inspection reveals the same javascript stuff firing up Silverlight. On the surface it looks the same. hmmm. I guess it isn't.
... here are a few extra things to look at for those who still have issues (I may as well list them
while they are fresh in my mind).
project / properties / Web / Debuggers: I now only have Silverlight checked. ASP.Net is not checked any more. (Not sure if this influences my result at this stage)
make sure your web project points to the silverlight project in project / properties / Silverlight Applications. This ensures that the silverlight project's binary "xap" is copied to a folder within the Web Site / Web App. Note: hitting the add button reveals a destination folder (should be ClientBin).
Your build configuration will add an additional sub foler e.g. debug.
Make sure your .aspx or .html files have the right path. For me, I just included the .ClientBin/debug/ folder. I don't think this is deploy friendly, so I will search for a better way later.
IE9 settings.
[X] Disable script debugging.
[X] Disable script debugging (Other)
[ ] Display notification about a script error
[ ] Show friendly HTTP error message
Again, unsure if these later setting have an impact.
Lastly, there's something that I forget about sometimes. Be sure to check Debug VS2010 / Exceptions / Common language Runtime. This ups the ability to catch exceptions.
I had a similar problem, but the above did not resolve it. However, starting the application without debugging (Ctrl-F5) and triggering the exception would allow me to select the Visual Studio instance that I started the application from. Amazingly, I got a sensible stack trace and resolve the problem within a few minutes.

Another knack on the "Dialogs must be user-initiated" Security Exception in Silverlight printing

I get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:
John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.
Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.
Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.
Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.
I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.
Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:
http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip
I wonder if anyone can reproduce?
Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?
I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml
<Button x:Name="PrintButton"
Content="Gotta print 'em!" Margin="8"
Click="PrintButton_Click" />
Don't feel bad about it. I did it last time through a misplaced Print inside a loop.
I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.
However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.
Try to remove
if(SightPaleceListBox.Items.Count > 0)
I had the same problem and found out that the reason was this following line:
cnvsMain.Children.Remove(PrintPagePlaceHolder);
cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).
My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.

Resources