Re: Step by Step skips large chunks of code

Hi Scott,

Thanks for your valuable feedback.

From your description of the problem, I found that this is a known issue to
Visual Studio 2008 SP1. It is logged at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=368650. The issue can be stably reproduced when another thread generates an exception.

The debugger product team has already identified the root cause of this issue. This is the words from product team:
"Sorry for the inconvenience, we made a late change to fix a different issue and introduced this bigger problem. We are working on a solution for this that should be available *soon*. We do need to ensure we have adequate testing on this fix, as it will need to be generally deployed. We should have our planned release date for this locked down in the next few days, but I would expect this to be about two weeks out."

Do your threads throw exceptions, too? You can verify it by opening menu [Debug]/[Exception], and check following categories of exceptions:
C++ exceptions
Common language runtime exceptions
Managed debugging assistants
Native run-time checks
Win32 exceptions
When running the application, the debugger will automatically break it when an exception is thrown.

Is there any way for you to avoid throwing exception from threads? If it is possible, I think that should be a quick workaround right now.

Regards,
Hongye Sun (hongyes@xxxxxxxxxxxxxxxxxxxx, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxxxxxxxxxx

This posting is provided "AS IS" with no warranties, and confers no rights.



"Scott" <snorberg@xxxxxxxxxxxxxxxxx> wrote in message news:D63C86AF-45A5-4AEA-A4AB-1B6166DFD9E5@xxxxxxxxxxxxxxxx
This appears to be a VS2008/SP1 issue. From a XP/32 bit machine without SP1
the debugger worked. Added SP1, the debugger started skipping within threads.
Then removed SP1 and now the debugger works.

I tried this same thing on a Vista 32 bit installation with the same
results. I am in the process of removing SP1. I will add to this when that is
finished.
--
Scott Norberg


""Hongye Sun [MSFT]"" wrote:

Hi Scott,

Do you mean that the debugger skips code only after multi-threads start
running? This is a very important information to this issue.

First, in order to isolate the problem, could you please stop running
multi-threads in your application? Check if the problem still remains while
no user created threads running in the application. You could do that just
comment the code to create new threads.

Second, let us monitor the threads in the Threads window. We could fist run
the application. When the breakpoint just before starting multi-threads is
hit, we could open threads window from menu [Debug] / [Windows] /
[Threads]. (The thread menu is only available when debugging) Inside the
threads table, it has thread id, category, name and location. Current
running thread is marked by a yellow arrow on the left side. Make sure
current thread is main thread. Then start stepping code. Check if the
current thread is always main thread.

The reason why we monitor the threads when debugging is because other
thread may hit the breakpoint when you stepping. That will switch the
debugger to other thread, so the main thread will not go on stepping
anymore in some situation.

Is it possible for you to create a small project that can reproduce the
error and you can send me through email?
If it is too hard, could you copy the routine code and thread running code
here or send me email so that I can do some reproduction attempts on my
side? (hongyes@xxxxxxxxxxxxxxxxxxxx, remove 'online.')

Please try to monitor the threads and let me know the result. Thanks.

Regards,
Hongye Sun (hongyes@xxxxxxxxxxxxxxxxxxxx, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@xxxxxxxxxxxxxx

This posting is provided "AS IS" with no warranties, and confers no rights.



.

Relevant Pages

  • Re: how can I create minidumps of second chance exceptions in .NET 1.1 managed code?
    ... Using the configuration like you suggested sends the exception to the JIT debugger which is registered in a system-wide manner, and I don't want to register there. ... ADPlus is usually good in catching 2nd chance managed exceptions." ...
    (microsoft.public.vsnet.debugging)
  • Re: visual studio exceptions performance
    ... Exceptions in the debugger are probably ... > We have a problem with Visual Studio .Net and the uncaught exceptions, ... > Microsoft Framework 1.1.4322 SP1 ...
    (microsoft.public.dotnet.framework.performance)
  • RE: Disabling exception trace messages
    ... a tick comparison shows the following: ... Outside debugger: ... > Can you tell me why this now takes so much longer than VC6? ... >> break on a given type of exception or on a category of exceptions. ...
    (microsoft.public.vc.debugger)
  • Re: Mixed assembly crashes on exit
    ... (when running the app under debugger, watch also for unexpected first chance ... exceptions in Debug Output window, or configure the debugger to stop ... Also try to set breakpoint in SingletoneDomainUnload function and step ... how does the disassembly around the place of crash look? ...
    (microsoft.public.vsnet.debugging)
  • Re: Set DEBUG flag at runtime?
    ... always break on exceptions, even if there was a catch block. ... debugger to break in the place where the exceptions occur when debugging, ... DEBUG mode rather than RELEASE. ...
    (microsoft.public.dotnet.languages.csharp)
Loading