I have inherited an application consisting of a number of C#, C++/CLI and native C++ projects.
The app starts as an MFC application but loads the CLR during startup (via a process I'm not sure I fully understand yet†).
I've found that I can place breakpoints in native C++ code and that these work as expected. However, breakpoints in managed code do not work.
In C# I get:
"The breakpoint will not currently be hit. No symbols have been loaded for this document".
In C++/CLI I Get:
"The breakpoint will not currently be hit. No executable code is associated with this line. Possible causes include: preprocessor directives or compiler/linker optimizations".
I can even set two breakpoints in the same C++ file and have only one work, e.g.
#pragma unmanaged
int CMyClass::UnmanagedFunc()
{
// Breakpoint here works
return 1
}
#pragma managed
int CMyClass::ManagedFunc()
{
// Breakpoint here DOES NOT WORK!!
return 2
}
The project settings for "Enable unmanaged code debugging" (within the managed library projects) has no effect on these breakpoints.
Is there some setting or config or something that I do do to allow me to interrupt and step through the managed parts of the code base?
†: The process loads mscoree.dll, and involves a complicated routine including CLRCreateInstance, ICLRMetaHost, ICLRRuntimeHost, GetRuntime(..), Start() and ExecuteInDefaultAppDomain(..).
Since your main EXE is a native program, it is likely that the debugger starts up in unmanaged mode and will therefore not support setting breakpoints on managed code. Project + Properties, Debugging, Debugger Type setting. Change it from the default of Auto to Mixed or Managed Only. Mixed debugging only works in 32-bit mode.
UPDATE: starting with VS2012 you also have to force the debugger to use the legacy managed code debugging engine, the one that still supports C++/CLI. Tools > Options > Debugging > General > "Use managed compatibility mode" setting.
For me, the key was to change debugger type from Auto to Mixed, but for the startup application, not the library which contained the C++/CLI code (which is what I was trying to do).
For the same error it works with me when I specified debugger type to:
"Native Only" or "Managed Only" not to Mixed or Auto!!!
For me it was in project properties -> Linker -> Debugging -> Debuggable Assembly set to YES (/ASSEMBLYDEBUG)
Related
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
In older version of Borland C++Builder you used the Console Wizard to start off a Win32 program. That is now gone from XE5! How do I start??
The wizard you are looking for is located at:
File > New > Other ... > C++Builder Projects > Console Application
However, the wizard dialog has been broken since XE2 and is still not fixed in the latest version (XE7 at the time of this writing).
The dialog has a drop-down list to select a "Target Framework". If you set this to "None", you may get "unresolved external" errors at link-time. So you might have to choose either "Visual Component Library" or "FireMonkey".
The dialog has a "Console Application" checkbox that is checked by default and disabled from user interaction.
As such, you can only create a console app that uses a main() entry point, rather than a Win32 app that uses a WinMain() entry point. Fortunately, there is a workaround in the Registry:
HKEY_CURRENT_USER\Software\Embarcadero\BDS\<version>\Repository\New Console Application
(REG_SZ) "ConsoleApp" = "True" or "False"
Set "ConsoleApp" to "True" or "False" to specify the checkbox's default state. By setting it to "False", you can create a console app that uses a WinMain() entry point.
Alternatively, another way to create a Win32 app with a WinMain() entry point is to create a new VCL Forms Application and remove the default generated MainForm from the project and remove any code you don't want from the default generated WinMain().
Embarcadero is aware of the bugs (I have discussed it with them in private, and they have confirmed there are some oddities in the dialog's code that are causing this issue). I don't see any QualityCentral tickets for them, so I have now submitted a QualityPortal ticket.
RSP-10796 C++ Console Application wizard is broken
Hopefully they will finally get fixed.
Basically my problem is that I expect Visual Studio (2010 Professional) to be able to evaluate any Visual C++ expression in the watch window that it handles in the code I'm debugging, but apparently there's something preventing this from happening. For example, when dealing with CStrings, evaluating the method IsEmpty on the CString in the watch window gives me a Member function not found error, as does a basic equality comparison (in the code being debugged obviously no problems).
Am I missing something here, or is what I'm asking for too much? Obvious solution would be to put debugging statements in my code for whatever CString operation I'm looking for, but I would prefer not to have to do this.
Update/Example:
CString blah = _T("blah");
Calling blah.IsEmpty() in my code works fine, but in the watch window of the debugger I get the error above (CXX0052). The contents of the variable blah can be seen the watch window.
I could reproduce your problem, and, indeed, the VS watch window shows Member function not found alongside with the error code CXX0052.
In the MSDN documentation I found that this problem arises due to a call of a inlined function, the CString::IsEmpty() member function is probably somehow inlined (this is what the Watch Window evaluator sees), to solve the problem, first open your project Configuration and disable inlining
Second, still in the project Configuration, choose Use MFC in a Static Library (somehow the Watch Window keep seeing the called function as an inlined one if you use it as shared library, maybe this is because in the Shared Library the code is inlined and the Watch Window evaluator don't use the Debug builds of such runtime libraries).
Third, clean and Rebuild your Solution.
After that, the problem should be fixed (remember to refresh the expression if you see the value grayed out in the watch panel) during debugging. Remember to switch back to your original Debug options or better, create a new Debug profile to keep this settings.
I'd like to humbly ask: How can I debug a wince executable(.exe) that has been stored on the wince device, using Visual Studio's debugging facility.
As we all know, using VS2005, we can create a Win32 Smart Device Project(.vcproj)，add our source files to it, compile, select a target device, and press F5, then the generated exe will be deployed to the wince device and gets attached to the VS2005 wince debugger. But I'd really like to know, if someone has a wince exe(call it stock) already in his wince-device and have source code corresponding to that exe, HOW DO I start debugging that stock exe directly WITHOUT compiling the source code? I cannot compile the source code perhaps because I'm missing some library source or other reason.
For PC program, I know I can open an exe as a project so to start debugging that exe. I can find the main() function and set a break point on its first statement, then F5 will stop at that break point.
Thank you in advance.
I often run into this problem as well; I wish the "exe project" created would allow changing the debugger to "Smart Device Native Debugger" (or somehow set the platform) -> Let me know if someone knows how to do that.
The two ways I have been able to work around this are:
New Project Method:
Create an empty "Smart Device" project with no source code.
Change the "Configuration Properties > Debugging > Remote Executable" to your "Stock EXE" that you put on the device, ie: \FlashDisk\MyApp.exe
F5 to debug, and choose "Yes" when it says "deployment errors, do you wish to continue".
Attach to Process Method:
Same as above, but, instead of editing "Remote Executable" just start the "Stock EXE" via rapistart.exe / running manually via screen. Then make sure the "Attach to Process" transport is set to "Smart Device" and you should be able to attach.
After this you need to manually load the pdb, choose src files, etc, as you would a normal PC app.
If you want to debug a .NET CF managed application then the following link should help:
http://msdn.microsoft.com/en-us/library/b1ksfbk7%28VS.80%29.aspx
I only used managed .NET CF but I found this link that has loads of goodies on how to debug both managed and native code on a Windows Mobile 5 in VS2005. Most of it should apply to Win CE as well:
http://msdn.microsoft.com/en-us/library/aa446524.aspx
I figure out the method lately after going through quite a lot of reading and experiment(so many tricky points that Microsoft does not clearly document). user2093823 kindly summarized the procedure.
Some historical screen shots:
I wanted to set breakpoint in the dll code so I introduced the statement "_asm int 3;". IE is supposed to open a dialog box saying that an unexpected exception has occured, and whether to close or debug. But it simply cuts down the window. The dll is a _Debug version not _Release version.
Another thing I noticed is that using the "debugger;" statement in the javascript code also causes the same behaviour - window dies without notice.
Why is this happening?
JIT debugging might be disabled. In your Visual Studio options, under Debugging > Just-In-Time, check the Native and Script options.
As an aside, you should probably call DebugBreak() instead of issuing _asm int 3. It's clearer that way.