CODEWITHSUNDEEP
c++.netvisual-studio-2010visual-studiodebugging
C. Tewalt
C. Tewalt

Reputation: 2509

What causes the Visual Studio Debugger to make some issues not reproducible?

Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.

If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.

For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.

But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.

Upvotes: 1

Views: 459

Answers (3)

C. Tewalt
C. Tewalt

Reputation: 2509

The correct and short answer. Run Windows Updates.

The correct and long answer.

It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).

But here's the kicker! If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.

http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build

Upvotes: 1

esavier
esavier

Reputation: 463

  • MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.

  • If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.

  • If its Windows app, try enabling/disabling LargeAddressAware.

  • If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine

  • debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.

  • most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.

  • in other cases, supply us with snippet, so we can tell something more!

@Matt this cant be heap problem, it can happen but its extremely rare.

@Huytard its wont happen, without linked dll's program should't even start.

Upvotes: 3

Son-Huy Pham
Son-Huy Pham

Reputation: 1899

  1. Running the green "play" button will use the IDE's environment
  2. Executing from the directory will use the default environment

My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.

Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.

For example:

@echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe

Upvotes: 0

Related Questions