** post was edited, more info below
I've just watched two great videos about Advanced Dotnet Debugging (by Brian Rasmussen) and I am trying to repeat some steps, but just don't know how to proceed with tis error:
An attempt to set a processes DebugPort or ExceptionPort was made,
but a port already exists in the process.
I've found some answers on google and i generally understand what the error says but I just don't understand one weird fact: when i compile my simple app < .NET 4.0, I can attach as the movie shows, trying to do the same after i compile targetting .NET 4.0 disables me from attaching.
One of google's answers says "try to attach from windbg using noninvasive mode" but.. Brian do not use any of such checkboxes. It just works on his videos.
What's the difference? Where's the catch? Is it Windows 7 vs Vista? Maybe some different compile settings matters?
I am using MS VS 2k10 with MS SDK with Windbg x86 downloaded from msdn and symbols correctly configured to http server. The system is MS Vista x86.
Resources (exact time >= 8:15):
http://channel9.msdn.com/posts/MDCC-TechTalk-Advanced-NET-Debugging-part-2
Edit:
Error shows when attaching to process that was run from VS. Trying to attach to process that was run /outside VS, windbg doesn't show any content.
Edit2:
Windbg had some refreshing problems in my system. Using few times "Windows \ [Undock | Dock all]" menu option i was able to see the content of attached process, that was missing.
So the only question now is: what's the difference when attaching to process started from VS, when it's compiled in once using target < 4.0 and again = 4.0? Why when targetting 4.0 windbg cannot attach to the process in not "noninvasive" mode. What has changed in VS 2k10?
I take it you're debugging from Visual Studio (F5) and then trying to attach. You can only have one active debugger at a time, so that is why you get this error. If you want to launch the process from VS, run it without debugging (Ctrl-F5). If you do that, you should be able to attach from WinDbg.
EDIT : I am sorry, I missed the point about various versions of .NET behaving differently in this respect, so let me try to address your questions again. The reason it "just works" in the video, is because I use run without debugging every time I launch from VS. So if you simply want to follow the examples in the videos, all you need to do is run without debugging.
I started using WinDbg/SOS on CLR2 and x86. Launching a x86 .NET process from VS back then would trigger the error, so I made a habit of just launching without debugging.
However, as you have discovered there are scenarios where you can actually attach to a process that is being debugged by VS. I can reproduce the scenarios you describe, but I can also attach to a x64, .NET 2 process started with debugging from VS2008, but I cannot attach to the same process if the platform is set to x86.
Apparently there are subtle differences that I haven't been aware of, and it doesn't seem to be related exclusively to the .NET version, as I can attach to a x64 .NET2 process even if it is under the control of the VS debugger.
I'll update my answer if I find additional details.
Related
I just installed a Windows 10 machine, since Windows 7 is now dropped... along with the old, classic VC6. Plus the Service pack 6, and the Platform SDK installed. I have been using it this way with no issues on my Windows 7 machine for decades (too long to go into why not upgrade to VS 2010, 2012, 2015, 2017, 2019, yada yada, yada... Subject for a different debate)
I brought up an existing project I was working in before the end of the year. Big exe, several DLLs in it, C++ objects, etc... Was all working fine before Jan 1st.
On my new Windows 10 install, when I tried to launch it in the debugger, it gave an error:
This appears even before main is called. And the executable immediately exists, even before the message box appears, so there is no stack trace to examine. Naturally I looked for any C++ constructors that might be called which could be corrupting things. But there were none. (and never had any issues on my Windows 7 machine anyway)
I narrowed it to the following condition:
The main EXE is linked statically to a LIB/DLL. THAT dll is linked statically to another LIB/DLL
When I remove the underneath DLL dependency, I can run the executable in the debugger.
I've found several projects that are experiencing this.
I have a test project (dsw and dps files) which demonstrates this (at least on my Windows 10 machine) if anyone wants to look at it. It is stripped down to nothing but shells. An EXE that is linked to a DLL, which is linked to another DLL. If I remove the inner DLL dependency in the link stage, the executable with a single DLL work fine.
Also, the EXE will run outside the debugger as well. Both debug and release.
Lastly, when I set the configuration for release, it also runs in the IDE, but has no debug info. However if I enable debug info in the release builds, it again crashes before startup.
So apparently there is yet something in windows 10 that is preventing the debugging container from running. I have also disabled the "Fault Tolerant Heap Shim" but no change.
Has anyone experienced something like this?
Does anyone have any advice?
-Scotty
I've been living without our V6 debugger for a few years now, and after doing yet another search hoping for a solution where I wound up here, I finally found a way and wanted to share it. For projects that give a user breakpoint error and exit immediately on startup, launch them with Build->Execute (ctrl+F5), then do a Build->Start Debug->Attach Process. You won't be able to do anything about the startup, but you can set breakpoints at timers or commands to get in. I guess you could put a long sleep as the first call in your main while debugging to give you a chance to get in and get your breakpoints in place there too.
Since Visual Studio 2017 version 15.8 we have on some computers in my team the following really weird build error.
Additionally Visual Studio recognizes it
but the IDE itself doesn't crash.
To check if it only happens to our own solutions I created a new simple, plain command line tool project which shows the same build behavior. So it isn't exclusive to our solutions.
I tried to get help from Microsoft but it seems they don't know what to do about it. The thread doesn't show all the material I provided to them. They got a lot of logs and a sample project from me. A crash dump wasn't possible to provide, because Visual Studio itself doesn't crash.
Repair and full uninstall, new install of Visual Studio didn't help either.
Edit: It is not only occurring on my development machine but on our build servers (there are two of them), too. Interestingly our VMs on the development machines does not seem to have this issue.
To me it seems, the problem has something to do with loading assembly from GAC, so I would suggest to try reinstalling Microsoft.CodeAnalysis assembly and see if it helps.
To Do that:
Install Microsoft.CodeAnalysis package to your project with it's required dependencies, make sure to note down all assemblies being downloaded.
Run Visual Studio Developer Command prompt as an Admin
Uninstall existing assemblies from GAC by using command gacutil /u [name of assembly] (do this for all assemblies from step 1)
Install newly downloaded dll using command gacutil /u [Path to Dll] for all dlls (do this for all assemblies from step 1)
Remove package from your project
I hope this helps!
Unfortunately in this case you have only three two options:
You could try to describe all the steps to reproduce this crash so much detailed as you could with a lot of screenshot images from this steps. Use for this DOC file format, PDF or some like that. This file you have to send to Visual Studio support.
You could try to create the crash dump. Each time Visual Studio crashes, it will create a dump file devenv.exe.[number].dmp file in the configured location. Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate drive space or adjust the DumpCount appropriately. I know, you wrote already on MS forum that this error doesn't create one dump. But would you like to imagine that you have 10 crashes on a day and on each crash one dump file in size 4 GB. will be written? The dump creating is disabled normaly and you have to enable it. How to enable it you could find using search string in Google: "How to enable dump files in Windows" or for Windows 10 you could see this video. Alternatively or additionally you could use the programm tool "ADPlus" for creating memory dump files and log files with debug output from one or more processes. This tool is very detailed describen on this MS Support page.
You could try to debug by yourself. But in the case if you want do it you have to see "Tools listing Included in Debugging Tools for Windows".
Normaly by Visual Studio support do not work the Visual Studio developers. You have to be nice to them and they do what they can do. You could not expect from them that they all know. They do their job using some given instructions.
In your case the support worker has gived you the link Reporting Visual Studio crashes and performance issues in which you have to read the following part:
Directly reproducible crashes
Directly reproducible crashes are cases which have all of the
following characteristics:
Can be observed by following a known set of steps
Can be observed on multiple computers (if available)
If the steps involve opening a project or document, can be reproduced in sample code or a project which can be linked to or
provided as part of the feedback
For these issues, follow the steps in "How to Report a Problem"
and be sure to include:
The steps to reproduce the problem
A standalone repro project as described above. If this is not possible, then please include:
The language of the open projects (C#, C++, etc.)
The kind of project (Console Application, ASP.NET, etc.)
Any extensions that are installed.
Most valuable feedback: For this case, the most valuable feedback is the set of steps to reproduce the issue along with sample source
code.
Unknown crashes
If you're not sure what's causing your crashes or they seem random,
then you can capture dumps locally each time Visual Studio crashes and
attach those to separate feedback items. To save dumps locally when
Visual Studio crashes, set the following registry entries:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe]
"DumpFolder"="C:\\Crashdumps"
"DumpCount"=dword:00000005
"DumpType"=dword:00000002
⚠️ Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate
drive space or adjust the DumpCount appropriately.
Each time Visual Studio crashes, it will create a dump file
devenv.exe.[number].dmp file in the configured location.
Then, use Visual Studio's "Report a Problem..." feature. It will
allow you to attach the appropriate dump.
Locate the dump file for the crash you are reporting (look for a file with the correct Creation time)
If possible, zip the file (*.zip) to reduce its size before submitting feedback
Follow the steps in "How to Report a Problem", and attach the heap dump to a new feedback item.
⚠️ Do not attach heap dumps to existing feedback items. Please create a new feedback item for each heap dump you would like to
submit. If you were requested to provide a heap dump in order to
resolve a previous feedback item, simply reply to the request with a
link to the new feedback item where the heap dump is attached.
Most valuable feedback: For this case, the most valuable feedback is the heap dump captured at the time of the crash.
Please read it very carefully and in best case two or even tree times successively.
I hope it will help you and I wish you good luck!
As suggested with Dipen in another answer problem seems to be in Microsoft.CodeAnalysis try reinstalling nuget package for that & re-register in GAC if missing.
If Issue still exists, you can try disabling code analysis on your project like:
In Project in VS 2017, open References & right click on Analyzers and click on Open Active Rule Set like:
Uncheck all rules so that no code analysis is done on your project like:
3 .Save All files and now try rebuilding & run the project to see if issue is resolved.
The issue was an older JustMock version installed. Could only solve it with the help of the Roslyn team.
When running a project in Test or Debug configuration in VB.NET using Visual Studio 2012, sometimes it gives the following error as the reason for "Build Failed"
Error 1 Could not copy the file "obj\Debug\MyProgram.exe" because it was not found. MyProgram
There are no issues with the code as it was just compiled seconds before this (sometimes I start the program again just to see how everything gets laid out visually and then go back to the code to make Location adjustments)
What I found is this. If I wait , when I go to test compile again -- it just magically starts working again -- Only to fail again later.
Sometimes, I can get 10-15 good compiles before it wigs out.
About my system configuration:
I do not have any other version of Visual Studio or standalone .NET language installed
The paths are set correctly (else it would never compile in the first place.. not just occassionaly fail)
The program can be a simple program with absolutely no code added (aka... New > WinForms Project > Compile)
The project, language (and all requirements), and project output path are on a local drive that is connected directly to the PC internally (using C:\code* for projects and the standard install location for Visual Studio 2012)
I checked the smart data and scanned my hard drive for any errors ... none ever encountered. The temperature of my system (CPU), and the drive is around 25-30 degrees C.
I am really baffled as to why this happens and at random. I have also tried completely clearing out the bin/ folder, and even Moving the project or repointing where the compiled output path is.
Deleting the .suo file helps sometimes, but not all the time.
I believe this is something that may be able to be tweaked in the UI somehow, however I do not know anything about manually linking and compiling programs.
Lastly -- it does not matter whether I run VS in "Administrator" mode (elevated privileges) or as a user.
Some methods that may help you
Have you tried to reinstall Visual Studio. If that does not work you may need to install some of Windows Updates, the compiler may be missing some essential libraries/references to compile your application.
Check your .Net Target Framework, setting your application to a new framework that you don't have installed can stop the application from compiling yet even stop it from being debugged, having a compiler that is to low, this may come with errors for the compiler but not for the IDE/Visual Studio to notice.
Try cleaning your project solution's output folder by right clicking your solution then try to rebuild your project/solution.
Check your compilation references in your project's properties, check if a reference added is not on your computer
Reinstall/Update .Net Framework, same here some requirements may be missing from your installation
Try installing a newer version of Visual Studio, try Vs2013 - this contains various improvements and fixes, Visual Studio 2015 is fast approaching, a recommendation install VS2015 when the full version gets released it will contain a lot of useful features for future .net programming.
Create an new Administrator account and Run VS with Administrator rights and try compiling then, this fixes some of problems in vs and other microsoft products, it might work here.
Install all of the .Net Frameworks from the lowest to current 4.5, this may help when some of the used references/libraries are not on your local hard drive.
if none of these methods work, i would not know of the problem one last thing you could try is installing Windows to another hard drive and try using that installation of windows and see what happens... Hope this helps.
Best regards!
I faced this kind of problem because of my virus guard
blocked my application(but it is not have any harmful code :) )
exclude your project folder from virus guard
or
simply disable it(not recommended)
I have my dlls (.NET4) build with msbuild and obfuscated with SmartAssembly 5.5.
After that i set them with reference for simple console application in the MonoDevelop (latest) on Mac (10.8).
Built ok, but when i ran that simple app, i have a message:
Unknown heap type: SmartAssembly
I asked SA support but no luck yet (the saproj have item blabla(supports Mono) checked.
I dont see how to attach a screenshot, but, when i run my application i see in the console that message twice. It appears before program stops on the breakpoint on the first line of code.
So maybe someone knows what to change in SmartAssembly or in MonoDevelop to remove this problem ? Thanks
Many .NET obfuscators change the assemblies such that they are not technically correct assemblies (they fall outside the .NET assembly specs) but such that they still run on the Microsoft .NET runtime by exploiting bugs specific to Microsoft's implementation. I suspect they do this to make it harder for assembly reader tools/libraries to load the assemblies. Unfortunately, this also prevents Mono runtime from loading the assemblies. In general Mono has a policy of not "fixing" support for this kind of invalid obfuscated code, so you'll need to ask SmartAssembly support for help.
If you're certain you're compiling with SmartAssembly's "Strictly valid" option and it's not working, perhaps you could perhaps try their "Basic" option.
I have Autodesk Inventor 2012 and its SDK, including add-in creation wizards, installed. I have created an add-in project (in VB.NET), and used the code from SimpleAddIn sample provided. .addin file points to the location of dll output of the compilation.
However, i have run into a following problem. When Inventor loads, not a single breakpoint in the add-in Activate function is triggered. Moreover, when i call the list of add-ins, mine is shown in the list as not loaded, and however i flag it to be, it does not.
What could be the reason for this behaviour? How can that be fixed?
Well, I assume that you're using RegistryFreeAddins being deployed via Manifests...
From the fact that your AddIn is listed in the AddIn Manager, I conclude that the registration works, but the loading at runtime fails. This can have those main reasons:
Missing Dependencies (in case you use third party assembiles)
BadImageFormatException (your AddIn compiled in x86 and you have X64
Inventor installed, which you always have in case you've got a 64-bit
OS)
Have a look at your debug output in VisualStudio. Do you see any Exception Messages, that would relate to your AddIn? If not, you could try to activate the "Managed Debugging Assistants" in VS (especially for BadImageFormat- and FileNotFoundException(s)). Just google the above phrase to see how it's done.
Hope I could help :)
Are you targeting .Net 4? Inventor 2012 supports only .net 3.5 it seems. I ran into the same problem and changing to 3.5 made my plugin load correctly.
http://forums.autodesk.com/t5/Autodesk-Inventor-Customization/Registry-free-addin-won-t-load/td-p/3488178
if for a reason or another, the library load crash in the Activate procedure, you will not be able to debug the solution.
So, clean the Activate sub and keep only necessary calls and try again.
If it's still not working, just PM me the Activate procedure and I'll help you.