I ask this Question because it is Moles specific.
Running VS2010 on Windows 7 64bit the VsHost of moles stays in the task manager, causing this message:
Unable to copy file
The process cannot access the file because it is being used by another process
Solution: Kill the Process Microsoft.Moles.VsHost.x86.exe in the Task-Manager
To do this very often is very very annoying. I read in the msdn social forum that this issue shall be fixe sometime (i recall the post was from 2010 but cant find the post).
This happens nearly every time I stop the Debugging of the Test or if there is an Error while Debugging.
Anything new about this Issue?
I very much hope that Moles will be a standard part of Visual Studio someday, because I like this Typemocking very much!
Related
I'm working on a disconnected network, so some options are a bit limited. Also, we have SAs who handle stuff like system updates (so, for instance, it is possible that there was a system update in there that I know nothing about).
However, I had 1.33.1, then 1.34.0, then 1.38 versions of VSCode working on my (Windows 10) machine. One day, for no apparent reason (I hadn't just installed something, for instance), 1.38 stopped working. It wouldn't even start up. Running 'Code --verbose' from the command line produced no output (the mouse cursor turned briefly to a spinner, but nothing even showed up in Task Manager, let alone something like a splash screen).
I did get an error message in the Application log, which included the lines (more or less; remember, no cut-n-paste possible):
Faulting Application Code.exe, version: 1.38.0
Faulting module ntdll.dll, version 10.0.16299.936
Exception code: 0xc0000374
Faulting Application path: c:\Program Files\Microsoft VS Code\Code.exe
Faulting module path: c:\Windows\System32\ntdll.dll
Re-installing VS Code (with or without system restart after uninstall) did nothing.
Removing all extensions (we have a bunch) did nothing
Installing 1.39.2 did nothing
The only good thing is that I can still run 1.34.0, if I reinstall that (did not try 1.33.1, and I don't have any in-between versions from 1.34 to 1.38 to try). So at least I'm not completely shut out.
I also tried deleting basically all of workspaceStorage, to no effect. Nor did renaming my storage.json.
The biggest weirdness, to me, is that the path to ntdll.dll is in System32, rather than in SysWOW64 (is there some way to force usage of the latter?). Second, why did 1.38.0 work just fine for a while, and then stop.
So, I'm curious if anyone else has seen this problem, and/or if anyone has any idea what else could be done to get more insight into what's causing this.
(edit: I plan to file bug for VSCode, but been waiting on confirmation email to finish creating my github acct for some time now. sigh)
I've had exactly the same problem twice. I'd been running the application since June 2019 and then in March of this year, Yep! Exact same problem as you encountered. A simple reinstall fixed that, but I've had the same problem again today and after some investigation, Windows 10 was telling me that I didn't have the right permissions to access the item (this is using the Owner's account!). Attempting to reinstall failed, with errors stating that the file / directory all ready existed and couldn't be overwritten or renamed. Attempting to un-install the application was only partially successful with the executable code.exe still remaining afterwards. The only way I managed fix it this time was to reinstall to a directory with a different name. Surprisingly though, all the existing workspaces, projects and extensions even were intact and the application opened where I had left off as though nothing had happened. This is a little worrying I have to say! But that's how I fixed it this time.
On all four of my Windows 7 x64 Pro computers with Visio Pro 2010 installed, I have had the following problem for the past several months: When I edit a Visio document that uses the UML stencil, as soon as I try to edit any object information, for example, define a table column, Visio locks up. By ‘lock up’, the program ceases to respond, Task Manager shows that the process is consuming 13% of the CPU, and the process has to be terminated via Task Manager.
In an attempt to resolve this problem, I had tried repairing the installation and uninstalling/reinstalling the program, but this has not resolved the problem.
I recently attached Visual Studio to the process to try to better understand the issue. As expected, there were numerous messages of the type ‘Cannot find or open the PDB file.’ The messages which, I sense, may be relevant were as follows:
First-chance exception at 0x7713C54F (KernelBase.dll) in VISIO.EXE: 0x80040155: Interface not registered.
In an attempt to address this issues, I tried:
C:\>regsvr32 c:\Windows\system32\KernelBase.dll
This resulted in a popup window with the following message:
The module “C:\Windows\system32\KernelBase.dll” was loaded but the entry-point DllRegisterServer was not found.
Make sure that “C:\Windows\system32\KernelBase.dll” is a valid DLL or OCX file then try again.
The version of kernelBase.cll that is currently installed is 6.1.7601.24214, dated 1 Aug 2018 with a size of 419,840 bytes.
I used MultiFind Pro to search C:\Windows for any files named KernelBase and found quite a few older version in C:\Windows\winsxs. There were also numerous folder of the type C:\Windows\winsxs\amd64_microsoft-windows-kernelbase_[identifier]. As well as other, similar folders. (What I am finding very strange is that MultiFind Pro is reporting a different file size and date than Windows Explorer or the Windows command prompt DIR command for all versions of this file.)
The last time a Visio UML file was successfully edited was Dec 2017 and based on the modified dates of the files found, the last version of KernelBase that was known to work was version 6.1.7601.23418, dated 18 Jun 2016.
I am fairly certain that my computer does not have a virus. I also know that reinstalling Windows will not resolve the issue as I have the same issue across all of my computers.
If I were to try copying Kernelbase.ddl V6.1.7601.23418 from the winsxs ‘backup’ folder, would it simply get over-written by the newer versions?
More importantly, can anyone suggest a specific course of action to resolve this problem?
Nikolay - I assume you are the MS Engineer who helped me with this issue - thanks.
Without boring everyone with the details: The problem occurs when my password manager, Sticky Password, is also running. Shut it down, and Visio works just fine. I have alerted the company and have asked them to fix the problem.
I just started using the included Development Kit that came with the CRM SDK. I created a simple plugin using the Development Kit and now I cannot find a way to debug the plugin. Before i started to use the Development Kit i was able to debug the plugins i created.
I attached the debugger to the w3wp.exe process but the debugger doesnt break on the breakpoint at all.
Moreover my assembly is registered on Database and with Isolation set to None
Any help would be greatly appreciated. Thank you
There is another way to debug (instructions toward the end), by copying the PDB to the CRM /bin and attaching to the asynchronous (or sandbox) worker process. I'm not sure which way is easier...I will have to try Piyush's way sometime, but I do not use the RegistrationTool anymore thanks to the toolkit:
Debugging works well once you follow the setup instructions, though
copying the PDB file remains a manual step. Also note, the sandbox
process (Microsoft.Crm.Sandbox.WorkerProcess) is not started until
after a plug-in is run, so you will have to invoke it (or another one)
at least once before you will be able to debug.
Some time back I wrote an Article to debug plugins in CRM 2011, this might help you out.
Debug Plugins - CRM Parking Lot
I found out what the problem was. Turns out you have to re-deploy the plugin after setting the Assembly with Isolation set to None. Then like Chris Snyder said you still have to copy the PDB file from the debug folder to the bin/assembly folder on the CRM server. Seems like that step is still manual. Will see if I can either find a way to do it automatically or just create a simble batch file to do it.
Thank you all for your help.
After setting up WinQual and WER for the first time, I intentionally inserted a crash in a release build expecting\hoping to get the WER dialogue but instead still get the dialogue containing "runtime error! The application has requested the runtime to terminate in an unusual way...".
Everything seems to be working correctly regarding the setup of WinQual (along with all the supporting symbol server, source server,WinQual account, submitted mapping files and verified their presence my WinQual account). Now I want to verify that dump files are created, submitted to WinQual and I can retrieve them for debugging.
I verified that my PC's (XP Pro SP3) error reporting is enabled (system properties-error reporting). I figured the hard part would be setting up everything above not getting the program to actually show the WER dialogue. Is there some modification to the exe or the PC needed?
It's good to know I may not be (completely) crazy. You're right that external issues were causing problems for the WER dialogue.
I changed the crash to the code above, just in case my version was too brutal, and ran the application on three machines and it appears that the presence of Visual Studio and/or just-in-time debugging, on XP and Win7, was affecting the WER dialogue. For anyone interested this is what I saw:
XP with Visual Studio. Asked to choose a debugger and if I chose No, the program exited without the WER dialogue.
XP without Visual Studio. Displayed WER dialogue and sent the error report (yeah).
Win7 with Visual Studio. Did not crash at all.
Win7 without Visual Studio. I have not tested yet but suspect it will behave correctly.
So as you implied, a combination of the crashing code and unrepresentative testing environment were thwarting my test.
Thanks so much!
If you are using a WinForms application there is a catch handler in it's event loop that pops up a dialog and prevents Windows Error Reporting (WER) from kicking in.
This call prevents this from happening.
(http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/176b7f8c-3efb-4e6f-8deb-c685c62629db/)
The magic line to fix:
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
There shouldn't be anything you need to do in the application to get it working. I suspect you've somehow managed to crash in some strange way that is not working too well with WER. Try adding a crash once the application has initialised, rather than during application startup (if that is what you're doing). I usually do something like this:
int* p=0;
*p=1;
Another possibility is that your machine isn't going to give you the same results as an end user because of the Just In Time debugger of Visual Studio, so try it on a typical end-user machine. A further possibility is that your machine is XP and WER support was at an early stage in XP and is better in Vista and Win7, so try crashing the app on a newer machine.
I am using Microsoft Robotics Studio for a school project and I am getting a strange error when I try to run the Visual Simulation Environment. It was working fine until yesterday and then suddenly it gave me a runtime error saying "Illegal command line arguments... do not use VPLHost directly, use dsshost instead to run a manifest" But I am only clicking on Run in VPL/DSS Manifest editor.
I am running MRDS as administrator and I even tried re-installing MRDS but it is still showing the same MS VPL Runtime error. I tried to search online, but cannot find any suitable solution.
I already tried running the existing samples, I.e. Urban Environment, Multiple Simulated Robots etc. but it still gives me the same error. The strange thing is that it was working perfectly one minute, and then started giving me this error message the next minute, when I had not changed anything in between. In fact, I had wanted to change something in my manifest, so I closed the running VPL application, closed VPL and opened DSS manifest editor, and ran my manifest and that is when I got this error.
What is going wrong? Is some MRDS script using vplhost32.exe instead of dsshost? If so, then where and how do I change it?
I tried running the urban envrionment manifest from the command prompt and Using DSSHost32 directly. This time, it didn't give me a runtime error but an intiialization error. I tried changing port numbers but it still doesn't work. I have deleted many files from my computer to free space (JIC) and it still doesn't work. The window just doesn't open even when I hover over it in Windows 7.
The error message looks like this: Only one usage of each socket address (protocol/network address/port) is normally permitted."
This was even after I checked netstat for free ports and tried but I get this error message. Its either this one or the "Don't use VPLHost directly" if I run it through VPL or DSS Manifest Editor.
Could it be that some external services are interfering with DSSHost/VPLHost? Are there any such services which I could try killing? ANY help/suggestion would help right now as my project is due Thursday and this is a really unfortunate time for it to be acting up like this.
Does the problem reproduce after logging off & logging back on? It's likely that you had a process hanging around that you weren't aware of. Logging off should shut down any processes you personally started.
I don't know the solution of your problem, but it would be better that you post your question on the link below:
http://p2p.wrox.com/book-professional-microsoft-robotics-studio-isbn-978-0-470-14107-6-410/
[official forum for the book : Professional Microsoft Robotics Studio], i hope you will shortly get reply there,
The other option is to post your question on the msdn forum,
http://social.msdn.microsoft.com/Forums/en-US/category/robotics
hope this would help....