Working on writing a custom property Handler for our custom file type in windows 7. I have installed the Windows 7 SDK and built the sample Property Handler. After registering the handler, it works great in Windows Explorer, but in the common file open dialog the custom values do not appear. Does anyone know if there is something special I need to do to get the properties to appear in common dialogs?
Explorer:
File Open Dialog:
OK, figured it out. Here is the deal. My app is 32 bit and I am on a x64 system. Because the PropertyHandler is written in x64 to support the shell out of process. But for the file open dialog it needs to run inprocess, so the x64 dll can not run. I confirmed this by creating a quick x64 app and the fileopen dialog works the same as the OS. Hope this helps someone else in my shoes later on, hate answering my own question, but don't want people wasting NRG on this one as I found the solution.
I'm fighting with VS 2010 and this error that seems to be very common in previous versions, but it looks like not everyone is having it in the latest version.
I've got VS 2010 SP1 and I'm getting this error quite often.
The problem is that it's not even enough to restart VS in order to make it go away, I usually have to restart my PC, and I'm losing a lot of time doing this (it's quite frequent)
I've got Windows 7 32bits (can't upgrade to 64 bits, the company doesn't allow it), and I can't do things like creating another solution (please don't reply this :) )
I've used the command to make devenv.exe LARGEADDRESSAWARE, but the error keeps on happening.
My virtual memory size is set to automatic, and the weird thing is that VS doesn't even take 2GB of ram, so I don't know if the error is really because it's lacking memory, or if it's some bug in the program
Any ideas, things to try, something?
I tried everything else as well. The problems continued to come back until I tried
http://blog.rongabriel.com/2010/03/08/not-enough-storage-is-available-to-process-this-command/
Edit: Link is dead, archived version: http://web.archive.org/web/20100929160038/http://blog.rongabriel.com/2010/03/08/not-enough-storage-is-available-to-process-this-command/
Click on Start > Run > regedit & press Enter
Find this key name HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
Locate IRPStackSize
If this value does not exist Righ Click on Parameters key and Click on New > Dword Value and type in IRPStackSize under the name.
The name of the value must be exactly (combination of uppercase and lowercase letters) the same as what I have above.
Right Click on the IRPStackSize and click on Modify
Select Decimal enter a value higher than 15(Maximum Value is 50 decimal) and Click Ok
You can close the registry editor and restart your computer.
This can be found under MS KB https://support.microsoft.com/en-us/kb/285089
Have a look at
Visual Studio 2010 -- how to reduce its memory footprint
I think I got the best results when I turned off C++ headers index. YMMV
Check the output project type in properties. In my case it was changed to "Windows Application" though it was a "Console Application".
Switching back to console application solved my problem.
I'm running Visual Studio 2010 with SP1, as well as R# 5.1, and a few other extensions (like PowerCommands and Productivity Power Tools). Somewhere along the lines, my debugging got super slow. If I use the F10/F11 keys to step, VS hangs for a bit and then steps. If I use the toolbar buttons for stepping, it's snappy as expected.
Any idea what's up with my shortcut keys?
I had exactly the same problem - extremely slow debugging with keyboard (F10 for example). Some symptoms:
if I click Step Into on toolbar, then everything works normal,
the lag during debugging is present not only in Visual Studio but anywhere (notepad, browser,...),
if I set any other browser as default browser in Visual Studio (I tried Firefox), then it works OK,
if I disable third-party browser extensions in IE, then it works OK,
if I enable third-party browser extensions and disable LastPass, then the problem is gone and debugging with keyboard is fast again!
So, try to disable LastPass extension if you have it or all extensions and try it.
Edit1 - somebody allready posted this on LastPass forum: http://forums.lastpass.com/viewtopic.php?f=12&t=61029
Edit2 - and here on SO also :) https://stackoverflow.com/a/8186670/1110039
I've found a deeper explanation for this problem.
I had this problem, with the symptoms user1110039 described BUT I haven't installed LastPass toolbar. And my default browser is Firefox.
Well, my application uses SetWindowsHookEx() function for setting a system wide shortcut. Which happens to be the reason for blocking F10/F11 debug keys (only in Windows 7 64 bits) It doesn't happen under 32 bits.
I've just removed the hook from the debug build and it works ok. I reckon the problem with LastPass is some system wide hook in the code of the extension.
I had exactly the same problem.
The problem was solved by closing the Watch window.
Try debugging with Firefox or Chrome. There must be something about the interaction with IE that is causing this behavior.
Disable "show threads in source" worked for me!
Calling DirectInput's Acquire() function on a keyboard device is what caused the slowdown for me. This is potentially related to the SetWindowsHookEx() caused slowdown - ie. that might be using DirectInput.
It's really odd that the keyboard stepping is slow while the toolbar buttons are not. Typically whenever I hear about a slow stepping experience my recommendation is to disable automatic property and ToString evaluation as this is the most likely cause
Tools -> Options
Debugger -> Uncheck "Enable property and .ToString evaluation"
I'm not very hopeful that will fix this instance. It sounds like a problem with a misbehaving extension that processes keyboard input. Your best bet is to disable the extensions one by one and see which one fixes the problem. I would do it in the following order
Productivity Power Tools
Power Commands
R#
Make sure you've installed Service Pack 1. I believe they fixed at least one significant performance problem in the debugger.
I experienced that very slow step by step debugging too, and fixed it by closing the threads window.
(Making a note here on an old thread, so it can be found in a web search.)
I normally leave the ==Disassembly== window open during debugging (I have a big screen.) I just discovered that single-stepping in the debugger can be speeded up by 50% if I hide that window too. The -tab- for it can exist and be handy - makes no difference - but the window itself shouldn't be showing. Ahah.
Have followed all the other suggestions and more from elsewhere, single-stepping is now about 8 times faster overall. (About 2.5 steps per second now.) Woo-hoo! Thank you all.
(I don't understand how they can write such slow UI code... I have a CPU here that's running at two billion cycles per second... that works out to about 400 million instructions per single step. Seems like Microsoft code could be a -little- faster... but then, I've never had the pleasure of using .NET etc.)
I tried all the suggestion and finally found that When I uninstalled VS2005, this issue got resolved. Note that in that machine VS2005
I was having this problem in my new job, where we use Visual Studio 2008 SP1. (Yes, I know, I know). Long delay on step with flickering hourglass. I always use F10, I don't even think about it, there's no way I could tolerate changing to the mouse or waiting multiple seconds for a simple step command.
I read through all the solutions provided here and elsewhere on the net with no joy.
Finally found the issue - I had set up my default language for the IDE as C#. It turns out the project I'm working on actually uses VB.NET, and when I set the default language to VB.NET (via Tools - Import and Export Settings) the debugger got so fast that I couldn't keep up with it and accidentally pressed F5 on the breakpoint I want to examine.
I hope this helps someone else.
In the end, the disabling of Last Pass in my browser (IE) was what solved this problem for me, but along the way I learned a lot of other things that could have just as easily been the cause. A variety of other valid answers to this question (Some in the various answers on this page) are validated and explained here:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx
This article explained that this F10 slowdown can be from having various diagnostic windows and toolbars open, Symbol loading issues, etc. and also explained what to do about debug slowdowns in general. It was an eye opening education that I think will continue to help me in the future should the F10 slowdown rear it's head again.
In my case it was the Call Stack window (Visual Studio 15.9.13) that caused the lag!
Even when I stepped over a very simple line like ++i; it took around 1-2 seconds until the debugger stepped over to the next line. Closing the Call Stack window or hiding it fixed the lag for me immediately.
This is driving us crazy... In VS2010, MVC2 projects, not all projects.... both on a project that was upgraded from 2008/mvc1 and on a brand new project created within 2010/MVC2, we have the following behavior:
1) develop as normal..
2) hit F5 or CTRL-F5 to open up a browser
3) works great!
4) add a CSS file (or JS file or any file, or remove any file) in the project
5) immediately the dialog pops up "WebDev.WebServer20.exe has stopped working"
You have to close the program, and "F5" again - and all is right with the world...
Say we then modify an existing css file. No problem. But adding or removing one, immediate crash.
It seems like the development webserver is "locked on" to the project file and when it detects a change, it dies.
The Event Viewer is pretty unhelpful. The following is logged:
Faulting application WebDev.WebServer20.exe, version 10.0.30319.1, time stamp 0x4ba204ca, faulting module KERNEL32.dll, version 6.0.6001.18215, time stamp 0x49953395, exception code 0xe053534f, fault offset 0x000442eb, process id 0x%9, application start time 0x%10.
This is happening on all of our developer workstations, which include some with Windows Sever 2008, some with Windows XP, and some with Windows 7. All are running VS2010 Premium with ReSharper.
Also, the same thing happens on projects which target the 4.0 framework, only the error message referrs to WebDev.WebServer40.exe instead.
Google has revealed nothing. We've already tried "setting a static port" instead of a dynamic port - no help.
Please help if you can.
So, as it turns out, the problem was due to a certain use of MVCTurbine and StructureMap, but it seems likely that the problem would also occur with other IOC Containers, not just StructureMap.
The author of MVCTurbine has expressed that the fix will be in version 2.2 of that product.
In the meantime, one extra line of code in your Global.asax will solve this problem:
//VNEXT: after Turbine 2.2 we wont need this line anymore...
protected override void ShutdownContext() { CurrentContext = null; ServiceLocator = null; }
This article shows the particular use case we were addressing. The "normal plain vanilla" use of MVCTurbine and StructureMap would not have this problem.
Obviously, great thanks to Javier for being so responsive to help requests!
There seems to be a rather annoying bug in MS Expression Web 3 (or perhaps an incompatibility with something else I have installed).
Quite often HTML code editor would refuse to copy things into clipboard. You select some text, press Ctrl-C, Ctrl-Insert or use context menu and nothing happens. Then in 10..15 seconds it would start working again... Then again it would not work. It's rather annoying.
Does anyone else have such a problem or knows how to fix it?
I'm running Microsoft Expression Web 3 Service Pack 1 Version 3.0.3813.0 on Windows 7 Ultimate x64 with all latest updates and patches. I have Russian keyboard layout installed. Other than that my system is pretty much plain vanilla.
There is now SP2, try using it, maybe it will solve the proplem.
Note : I don't have this proplem