www.virtualacorn.co.uk/forum

VRPC has run very reliably for a long time but in the last few months, when it gets interrupted by some application that forces it out of full screen mode its very likely to crash with postmortem dump. This is especially annoying now that the new UniServerFS sends MSWord files to MSWord when double clicking on a Word file in RIS OS. MSWords fires up and loads the document but a second or two later VRPC goes bang.
I'd save the dump data if I could but there is tons of it and you can't copy it off the screen and I can't copy the temporary dump file because its locked and it deletes the dump file after the error window is deleted.
Increasingly there are more and more Windows apps that interrupt VRPC and various of them crash VRPC.
Any known solutions?

What you seem to be saying is that VRPC used to be fine, now you've installed the new "UniServerFS" it isn't. So try un-installing UniServer and see if the situation improves.
I am not sure what UniServer does (Andrew at RComp us ill so I can't ask him at the mo) but if all it does is allow a file to launched under the Host Operating System (Normally Windows) then it's totally pointless as VRPC can already do this.
Take a look at the RISC OS task manager list and see if you have the "VirtualAcorn Windows Controller" running. If you do then to launch a file with a .xxx extension on Windows just hold down ALT GRY and double click on the file.
If you don't have the Windows Controller send me an e-mail and I will dig out a copy.

Just recently this issue has become a little clearer. I've inadvertently left the laptop on battery and Windows has emergency hibernated and powered down. Each time VRPC gets into a state where it will not respond to anything and it has to be shut down from Windows and restarted.
VRPC also hangs or crashes sometimes when it is interrupted by Windows processes which are running and detect some update has become available. This doesn't happen often and it doesn't always cause VRPC to crash but when it does much work can be lost. The worst culprit for causing this is the Trend PC-Cillin anti-virus software.
These crashes are now confirmed to have nothing to do with UniServerFS because its not present on the laptop.

Sorry, This is off-topic; but I am curious - what is UniServerFS?

It's a part of UniPrint from RComp. It allows files to be launched onto the Host OS from inside RISC OS. Whilst I am a big fan of UniPrint itself (hardly suprising since it was my idea) I think that UniServerFS is rather nasty and is a bif ot a cludge.
Since all VRPCs have the facility to send a file to the Host OS anyway* it's completely pointless and just causes problems.
*using the HostOpen command - with a keyboard controlled front end called the "VirtualAcorn Windows Controller". If you check the RISC OS Task Manger you may find the VirtualAcorn Windows Controller running. If so then ALT double clicking on a filetype known to Windows (JPEG, HTML, Text etc) will load this file into the appropriate Windows application.

OK, Thanks.

Its been over a year since this issue was raised but I want to re-open it because it is a serious problem.
As I said originally, when VRPC is forcibly interrupted by a Windows application (usually, but not always, some kind of error announcement) VRPC frequently (but not always) crashes.
This was especially annoying today because I was trying to print some business cards using UniPrint and because of the useless printer the business card sheets kept jamming. Windows then forced VRPC out of full screen mode to announce the printer jam and over 50% of the time VRPC then crashed. I've had to reboot VRPC about 10 times to get 5 sheets of business cards.
However, this isn't the only reason for the crashes (i.e. its not UniPrint's fault). Babylon 6 has an annoying advert that pops up and that sometimes crashes VRPC. Various other things cause the same problem (fortunately not very frequently, but sometimes a lot of work is lost).
So how can we track this down? Is there some way to backtrace the crash to see what happened? I'd be very interested in helping to resolve this, if you can tell me how to get relevant info.

The priority of this needs to be raised because this is now happening a lot.
Since I've scripted the transitions between VRPC full screen and a hidden window using AutoIt (see post in the programmers section of the forum) the crashes are much more frequent.
The crash seems likely to be related to the particular way the VRPC window gets 'hidden' or minimized following an Alt-Enter or forced transition back to windowed mode from full screen. I've noticed that if this results in a blank button being attached to the task bar (usually above the task bar, but once it obscured the Start button), then frequently a lot of disc activity starts and a few seconds later the "VRPC has encountered a problem..." message appears.
I've tried to capture the crash report but the file is locked while the crash message is on screen and instantly I dismiss the error box the file gets deleted - stupid Windoze!
I'm now experimenting by tweaking time delays between actions. For example, the delay between the last filing system access in RISC OS and the Alt-Enter, and time between Alt-Enter and hiding the VRPC window. The non-crash situation seems to be when these actions result in VRPC being hidden without putting the blank button above the task bar. I'm not yet sure what this means.
Can anyone interpret these clues?

I wonder if this is possibly related to the crashes I have described here

My situation a certainly more complicated than I first thought.

All I know is that VRPC closed down with the same (windows) message which you are seeing, although I can not now reproduce the fault.

I'm not sure whether your problem is related.
What I now know about the crashes I'm seeing is:
a) they are only involved with full screen to windowed mode transition
b) they are dependent on timing (i.e. how quickly the VRPC window is minimized or hidden after the change to windowed mode.
c) they are intermittent (sometimes the mode change doesn't cause a crash). The fact that I am now triggering the mode change by deleting a directory in RISC OS (which the AutoIt script takes as its cue to send Alt-Enter to VRPC) seems to have made the problem worse and that may be due to timing (b above).
d) crashes never occur on manual mode switching. I think this is because nothing from the Windows environment is doing anything with the VRPC window, whereas when a Windows app/process forces the mode change its also hiding/minimizing VRPC.

I think I'm at a stage now where I can cause a crash almost every time using the AutoIt script to hide the VRPC window immediately after the Alt-Enter with no delay. With a 500mS delay it seems to be OK. But this is system dependent because I haven't seen crashes anywhere near as often on my 3GHz 2 core CPU with VRPC-SA as I do on the 1.6GHz 2 core XPC Shuttle with VRPC-SE.
Perhaps its time for the VA support guys to take a look at the code and see if there might be a race condition where for example VRPC might try to write to the full screen when its gone. I'll be happy to run some debug stuff if that helps find this gremlin.

An additional clue to the cause of this crash has emerged. Today it was at first impossible to use Uniscan because the printer software forced VRPC out of full screen and a crash occurred almost every time.
This was because the "allow WIA dialog to open" option somehow got re-enabled (how I don't know).
But what I noticed was that VRPC seemed must more likely to crash
if whilst it was in windowed mode the window size was changed, or any other window event was delivered to it (such as mouse click). If I simply waited and then manually hit Alt-Enter it didn't crash. So again it looks like VRPC is trying to access the full screen buffer when its gone (probably the Windows equivalent of a seg fault).
So it seems that the method used to force VRPC out of full screen is probably not being acknowledged in the way it does with the Alt-Enter.

This crash when interrupted by Windows applications is becoming more and more disruptive to serious work. Twice this week (whilst I was away leaving my wife in charge) VRPC crashed. In both cases it was because the temperature sensor receiver had stopped and I have a monitoring program that displays a message on the Windows Desktop when this happens. This message is produced by a simple script running under AutoIt that opens a message box. I've not done anything special to have this interrupt VRPC, its just the normal operation. Thinking about this a little more I suppose that most of the time when you're using VRPC nothing happens in the Windows environment, but it seems that when anthing opens a new window in the Windows environment it is HIGHLY LIKELY to crash VRPC. Its now caused the loss of a lot of work several times and I believe we need to try to find the root cause with a view to fixing it.
VA Support, can you make any suggestions? Thanks.

I have an Asus board with temperature monitoring. This does not cause the problem's you are describing - indeed in this case the temperature/fan etc readings appear on top of the RISC OS desktop (even when in full screen mode). I have never had the problems you are describing - is it AutoIt that is causing the problems?

As far as I can see you have a fault on the machine (temperature sensor failing randomly) which triggers an app you have set up, which then crashes VirtualRPC. We can certainly take a look at it when I am back in the office in the week starting 15th of June however the main problem seems to be with AutoIt.

There appear to be different ways that Windows apps break thru. One is what I suspect your temp monitor is doing - to open a window that appears over the top of the RISC OS full screen (such windows don't have the standard window furniture, no scroll bars, etc). These don't cause any problem. For example, the AVG antivirus sotware shows the progress as its scanning emails. It appears bottom right and pops up and disappears as status changes. The other way windows appear is the one that causes the crashes. These usually (but not always) appear to be full Windows-style windows with all the usual furniture. This is what AutoIt is opening. But its definitely not just an AutoIt problem. For example, Babylon 6 was a real pain - it would open advertising windows that sometimes crashed VRPC. Another example is when the printer runs out of paper or ink and wants to tell you about it. There are any number of things that can do this.
I don't know enough about Windows to know the difference between the various styles of windows, or the methods used to open them, but there are definitely those that crash VRPC and those that don't.
I thought it might be to do with writing to the window when the full to windowed transition occured but thats not a problem - I proved this by experiment.
I'm sure there is a race condition involved. If I get AutoIt to minimize the VRPC window too soon after issuing an Alt-Enter it will cause a crash. I've worked around this by adding a 200mS delay between Alt-Enter and the minimize. The problem is that I don't have control over other software which is doing the same without a delay. My suggestion is to investigate this minimizing after Alt-Enter as I think this is whats going wrong.
There also seem to be two ways of minimizing - the one where the button appears in the usual place on the task bar and the one where a button is added above the default task bar (which requires two Alt-Enters to get VRPC back to full screen). This latter one seems to be the most likely one to crash VRPC but having said that, when I program AutoIt its actually doing a 'normal' minimize.
Another contrasting situation is that I have a windows memory optimizer running (...and before you suspect that I'll hasten to say the crashes occurred before I started using it) it opens a window briefly to show when its doing its job. That window doesn't appear on top of RISC OS and so its no problem. So not all window opening operations lead to a VRPC crash.
Sorry about my ignorance of Windows API operation here - I'm describing this from user observations and trying to deduce whats going on under the hood.

In order to provide more clues a few other things occurred to me.
Messenger and Skype have popups which show when contacts come online. These don't cause a crash (I believe its because they are not causing VRPC to leave full screen mode).

To address your point about the temperature fault. There is a fault but its not in the computer, its in the receiver software that collects data by RF from sensors around the house. Because it stops randomly I have the AutoIt script running to warn me that its stopped because it needs manual intervention to reset the receiver. This has nothing to do with the point of this topic. Its just that using AutoIt I now have a method of causing VRPC crashes at will, whereas previously I had to wait for a Windows app to cause it. This is useful as it makes it easy to experiment with timing of user key entry and window control. So I'm quite willing to do some experiments if that helps, but I'm pretty sure its a problem with minimizing too soon after the Alt-Enter (or whatever program-initiated event is equivalent).