I wrote the following code in .vimrc to save last session of vim. Normally, it works. But when shutting down Windows, it doesn't work correctly according to the error of failure about starting vimrun.exe.
au VimLeavePre * call xolox#session#auto_save()
The auto_save methods uses vimrun.exe. As you know, it happens because Windows prohibit a new process to start on shutdown.
Is there any way to avoid the failure?
Windows 7 x64
gvim.exe 7.4
Well, there's no arguing with Windows, right?!
As mentioned in the comments, you could move away from the plugin to native :mksession, but you'd lose all the plugin functionality (which I use and like, too).
You could ask the plugin's author for a lightweight auto_save() fallback that doesn't need to shell out.
Or avoid the problem altogether by saving earlier and more frequently. In GVIM, the FocusLost event would work well.
Related
I have the following bug in a program:
An MDI MFC program closes silently on Windows 7 (terminates the process without prompting to save changes and without displaying any "crash" dialog) when the user performs this operation : Click a context menu item.
But this happens only on that PC, at least, for the moment. No other PC has encountered that problem. However the bug can always be reproduced following the same steps but only on that PC.
I want to know the reason but probably the customer won't allow me to install many programs to debug, so I need to be able to log when the program terminates, or print the stack in Release version but I'm quite lost.
I had faced a similar bug before and eventually I fixed it logging line by line and changing the problematic part, but I guess there are much better ways to find bug reasons than this.
I have tried on my development PC to create minidumps on Release mode but if there is no exception thrown on that PC, (I haven't confirmed that yet, though...) maybe it's pointless.
Also used an available class on codeproject (Stackwalker) but I don't manage to print all the function calls. Only on simple console programs, but not on MDI or even SDI.
Any ideas on how to find out the reason? Thanks in advance.
I'd like to write my own (very simple) explorer.exe alternative that I could actively switch between without having to restart my computer.
Is it possible to run two shells simultaneosly (or to write a program that temporarily disables the current shell)?
If not, is it possible to stop explorer without it restarting itself, and have my shell start itself instead?
Edit
More info: I'd like to write a simple productivity tool for myself. I want to set up a very simple task manager that prevents me from starting/opening/using anything but a whitelisted set of applications I list ahead of time. Locking me into that set of apps for whatever time period I've set. If there's another (better) way to prevent people from shutting down my app, switching from my app (with alt-tab, etc) I'm all ears.
Note: I'm fine with the app/shell/whatever being escapable by restarting my computer. I just want to make it massively inconvenient to switch to being distracted, and I wanted to learn a bit more about the Windows API.
See this question for details about writing a shell.
No, there can only be one real shell process (SetShellWindowEx only works when there is no other shell process) WH_SHELL can be used by other processes and it might be enough for your needs (Maybe in combination with IShellExecuteHook)
When explorer.exe is started and it detects a different shell it will not display the taskbar, just a file browser window. Explorer also looks at the shell value in the registry IIRC. You might also want to look into the shift to exit trick.
Windows 7 is caching some of the COM class information. Older OSs didn't do this. After the OS looks up theHKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value, it caches the value, and doesn't look it up again.
When we update our software, we place the new updates in a different directory, and then update the HKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value to reflect the new path. The next time the software runs, it will use the latest files if running under older Windows OSs. However, on Windows 7, it will continue to use the older file, until the OS is rebooted.
I ran process monitor, and discovered that under Windows 7, it never reads the registry key again, after the first read. On older OSs, it reads that key every time.
My question is: Is there any way to force Windows 7 to re-read the LocalServer32 information from the HKCU hive each time a new out of proc COM object is created?
I have only been able to solve this problem by...
1: Stopping the Process
2: explicitly unregistering using regsvr32 the library ( or exename /unregserver)
3: Registering the new component
4: Starting the process back up.
I would suspect that it is the Un Reg part that is failing for you. If you are just changing the registry key directly then you should call RegSvr32 /u instead.
Also make sure the new directory location is the current directory when you call RegSvr32.
Note that I have always stopped the process and then unregistered, this is probably a significant detail.
As this is a top result in Google for this narrow-ish problem, I thought it would be valuable to add my troubleshooting outcome for this problem.
I found this response on SO: C# : How to change windows registry and take effect immediately
And linked solution from that answer: Registry Watcher C#
Both of which seem viable options for managing changed keys without forcing a reboot. For us (like the OP) this was when installing updates. For us (possibly unlike the OP) this is infrequent and we decided the effort to implement and test a fix as described was outweighed by the simple solution of requiring a reboot: a process Windows users have come to expect with installing software anyway.
In the second example (in the section examples) on this link, there is a description on using WM_QUERYENDSESSION to abort a shutdown. It also states that this does not work on versions of windows later than XP. This is conflicting with the advice given on another question here at stackoverflow. What is the correct answer? I do not have a computer with either so I am unable to test.
Some applications got the WM_QUERYENDSESSION handling wrong (Not passing to DefWindowProc, they incorrectly returned 0 even though they did not intend to block shutdown) and so MS changed it with Vista, you now need to call ShutdownBlockReasonCreate()
#Konamiman: shutdown.exe -a will abort a "scheduled" shutdown yes, but not a "normal" shutdown by someone calling ExitWindowsEx()
If anything else fails, remember that from command line it is shutdown.exe -a; maybe you could invoke this using the Process class.
EDIT. When mentioning the Process class I happily assumed that the question was about .NET programming, now I see that .NET is not mentioned neither in the question nor in the tags. Anyway I believe that there are ways to run executables from other programming environments as well.
Is there any "Boot session ID" or (reliable) "Boot timestamp"?
For an installation I need to detect that a scheduled reboot took place indeed.
I guess I could do a dummy MoveFileEx() with MOVEFILE_DELAY_UNTIL_REBOOT, but i did hope for something easier.
(We have to install a 3rd party package that sometimes behaves erratically after an repair/update. In that state, accessing the device may even lock up the system)
(Windows XP, Vista, 7)
For things like this, WMI (Windows Management Instrumentation) is often a good starting place. I know you can get current uptime directly through it, which may allow you to determine if a machine recently rebooted.
Here is a blog post with some code samples as well:
http://blogs.technet.com/heyscriptingguy/archive/2004/09/07/how-can-i-tell-if-a-server-has-rebooted.aspx
Depending on your implementation language, you probably just want to pull out the query code from the vbscript.
Apparently Windows has the equivalent of "uptime". Here's more info: http://support.microsoft.com/kb/555737
As I understand it, this should tell you how long ago the system was booted. Will that information solve your problem?
You could search the System event log for event 6009 from the EventLog source - this is the first event recorded after each reboot.
I think the best answer has already been given here: Find out if computer rebooted since the last time my program ran?
That seems to be the simplest way. Use GlobalFindAtom() to see if it exists and create it, with GlobalAddAtom(), if it doesn't. It will persist beyond the execution of your program. If your application runs again, and sees that the atom exists, then then it isn't the first run since reboot.
If the computer is restarted, then the atom won't exist, indicating that this is the first run of your program since the reboot.