I very rarely close down Visual Studio intentionally. The project I'm working on is so ginormous that it takes about 15 minutes just to load it up, so it's been my practice just to leave the solution open overnight so that it'll be ready for me the next morning. The only time I have to restart the program now is if it crashes - which - happens. Every once in a while I'll do something it doesn't like and it quits on me. I accept this. I'd love for it to be bullet-proof, but I hardly expect that.
The downside of this is that apparently, any settings you change in the program while it's running (fonts and colors, keyboard shortcuts, auto-formatting settings, basically anything in the Tools/Options dialogue) are only saved when you quit the program legitimately. These settings are not saved when it crashes. So I find myself having to redo any settings changes I made every single time.
First off - why the heck doesn't it save the settings when you change the settings? How hard would that be? It's a certain level of hubris to take it on faith that your program will always close normally and not bother saving state until the shutdown process. (And not having it save settings in an abnormal shutdown process either) I'd get fired (or at least reprimanded) for writing code that did that, so how does Microsoft get away with it? And is there some way of forcing it to save settings without quitting and reloading?
As far as I know, the only thing you can do in your situation is to export your settings directly after you change them, and import them after a crash. This way your settings are safe, and you don't need to restart.
Related
Whenever I am debugging a new program by pressing the "Start without deubgging" button, sometimes it will open up a blank program like this:
I can not close these blank programs at all no matter how many times I try and close it, even with the task manager. And if I try to debug it again, it just opens up another blank program. The only way to fix this program is to either restart or shut my computer, but doing that tedious and I don't want to do that every time this happens. Is there a way to prevent this or at least close the blank programs? Thanks!
I just started a new task at a "lower level" in the platform stack, and I'm getting started with windbg. I'm so far quite happy with the pure power of the debugger. However, I wish it would just save my session default, like the VS debugger does. What I want is that whenever I ".restart", or re-open windbg, it works just like I left it: same bp's, same sxe state, same files open in the same places, etc.
I know about "save workspace" which seems to do what I want, but it's manual, and I have to do it every time I make a change to the workspace state.
Is there a way to just have windbg do this automatically?
It should prompt the first time you close the session and ask you if you want to save your workspace, there is a checkbox like the image here.
If you click yes this time and the box 'Don't ask again in this WinDbg session' then it will automatically save your workspace, similarly you can also clear the workspaces if it's erroneously saved some breakpoints or paths that you are no longer interested.
Also you can set this in the options like so:
Microsoft NTDebugging Blog. Uncovering How Workspaces Work in WinDbg.
I am planning to start my application whenever the user starts the computer. ASFA I know, there are two options available to me:
put the application link to startup folder
Keep a the startup-registry location updated with application path
However, the problem is, AVs like Kasperesky reports the registry paths (if added by an app) as keyloggers. Just wanted to hear from you people, which is better? Adding a shortcut to startup folder or using the registry way.
I really would prefer that you didn't force my app to start whenever I reboot. So, if you really insist, then please put it in the Startup folder and don't hide it in the Windows registry where I will never be able to find it. There may be times when I need this thing not to start up every time, so please let me do the choosing by putting the shortcut where I can see it and manage it. Otherwise, if it gives me too much trouble, I may just start up Control Panel > Add or Remove Programs, and you really don't want that, do you?
Example: i'd like to always see "CPU Registers" and never see "Scripting Console".
Using Code::Blocks, how can i do this, regardless of the project i use?
You realize the CPU register window won't show anything unless you're actually debugging right?
Anyway, to save a perspective in C::B, setup the IDE to the layout you want and just save it. In your case, you would do something like the follow:
have the debug toolbar visible. Enable it by going
to View->Toolbars->Debugger.
display CPU window from debugger toolbar. Find 'Debugging
windows'->'CPU Registers'.
Hide the scripting console. Go to View->Script Console and uncheck.
Set the layout to your preference and save. Go to View->Perspectives->Save current. Give it a name.
The next time you start C::B it'll use the last perspective you were on when you quit. So make sure you exit C::B with the new saved perspective.
I am currently working on a program to immediately clear the list of previously-run-commands which appears in the Windows Start -> Run dialog. The procedure for clearing this list by removing the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU key is well documented; however, before these changes take effect, it seems to be necessary to do one of the following:
Restart the computer
Select Start -> Shut down, and then select Cancel.
Neither of these is ideal for the task I am trying to accomplish: #1 is extremely disruptive to the user, and #2 appears to require additional user interaction.
Does anyone know how to immediately (and programmatically) force a reload of this information without requiring any user interaction, while also minimizing disruption of the user's other activities? I would like for the user's Run history to be cleared out immediately after executing my program, without requiring any further action on their part (such as using the "Shut Down" -> "Cancel" trick in #2 above) or forcing a reboot.
Or, to approach the problem from a different angle: When clicking Start -> Shut Down -> Cancel, Windows Explorer reloads the RunMUI key. Is there a way to force a similar reload without having the user select Shut Down and then Cancel?
Things I have already tried:
Monitoring the explorer.exe status using procmon while selecting Shutdown and then Cancel. I see Explorer writing to the RunMRU key, but have not been able to determine what triggers this.
Numerous Google searches along the lines of "reload runmru without reboot". Most results still recommend method #1 above, although a few suggest #2.
Limited MSDN API examination. The RegFlushKey call appears promising, but I haven't ever used it before, so I don't know if it will apply to registry information cached by different processes.
Any suggestions or other information would be greatly appreciated.
Have you tried ccleaner?
http://www.ccleaner.com/
Not a full answer to your question, but I did find a third way to trigger the clearing of the run command from this article in PC Mag.
Killing explorer.exe and then restarting it will also clear the run list after the registry modification.
I have a nasty hack for you. Show the window programatically, hide it immediately (programatically) and click cancel on it (well, you guessed, programmatically).
You might try looking for the icon cache flush API, or other ones, I wouldn't be too suprised if they had side effects like the one you are looking for.
I've seen instances where it actually works, even the F5 key doesn't work? Try this, ctrl>alt>delete then go to task manager, processes tab...end explorer.exe. Then click on file new task and type explorer.exe, then check...does that work?
Windows XP
Right click on the taskbar
Properties menu option
Start Menu tab
Customize button
Programs pane
Clear List
Click on OK
This calls a Windows API function that refreshes the explorere.exe taskbar process and also clears the list (no need for registry edits).
As far as I know, it relies on the explorer.exe process that hosts the start menu/taskbar/desktop being closed and reopened. There is no "clean" way to do this that I am aware of.
If you really need to do this without user interaction, you need to close all explorer.exe processes and relaunch one.
Here's a rudimentary C# program to do that;
using System.Diagnostics;
Process[] procs = Process.GetProcessesByName("explorer");
foreach (Process proc in procs)
{
proc.Kill();
}
Process.Start("explorer.exe");
Note that this will close all "Windows Explorer" windows open, and may or may not open an additional "Windows Explorer" afterwards.
I just tested that on Windows XP 32bit, and it did indeed clear the Run command cache.
HKEY_CURRENT_USER\ Software\ Microsoft\ Windows\ CurrentVersion\ Explorer\ RunMRU\