Fatal error and weird behavior openMSX/catapult

Ascended (8261)

23-11-2017, 21:01

I just downloaded and installed openmsx 0.14.0 on a windows laptop (haven't tried a previous version with this computer). I have an issue related to catapult, and an issue related to openmsx itself (I think):

When starting catapult, it doesn't search for working machines and extensions. It simply displays the scan window and no progress is made.
When starting openmsx, I get this message: Fatal error: SHGetSpecialFolderPathW failed: 64.

Any idea how to fix this? For the record, I run windows 7 64-bit on this machine, and my user profile directory is synced with work (which I can access only when connected via VPN). I guess this may be part of the reason...

ログイン/登録して投稿

By mfeingol

Champion (293)

23-11-2017, 21:11

openMSX is asking the OS for your Documents folder, and the OS is returning ERROR_NETNAME_DELETED.

So yeah, odds are your user profile redirection is the cause of that error. I suppose it works when connected to the VPN?

By [D-Tail]

Ascended (8261)

24-11-2017, 09:52

Catapult scans for working configurations when connected to the VPN. But it's REALLY slow, even though the system ROMs are all stored locally on my C drive. I'm thinking it searches for system ROMs in My Documents then first, while it should just look into C:\Program files\openMSX\share.

Also, as I press the "Start" button in catapult, it takes a long time (1 minute or so) before the openmsx main window opens. Once started, it does run smoothly. The 2nd time is faster, it (only) takes 5 seconds to fire up the main window.

Is it possible to have openMSX/catapult skip the My Documents folder at all? This VPN slowness kind of spoils the fun...

By [D-Tail]

Ascended (8261)

24-11-2017, 12:52

Also, half of the time starting openmsx just fails while VPN is connected, with a different error code this time:

Fatal error: SHGetSpecialFolderPathW failed: 53
Fatal error: SHGetSpecialFolderPathW failed: 3

Is there a reference for what these return codes mean? The MSDN page only talks about a HRESULT that is returned...

By Manuel

Ascended (19228)

26-11-2017, 16:15

https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms681382(v=vs.85).aspx Google for Windows system error codes.

You could try to set the environment variable OPENMSX_USER_DATA to a different path.

By [D-Tail]

Ascended (8261)

02-12-2017, 15:13

I updated the OPENMSX_USER_DATA environment variable to point to a local dir. Now catapult starts up and scanning for MSX hardware works. So far so good.

Starting openMSX itself still gives error code 53 (ERROR_BAD_NETPATH) as indicated in the previous post. Let me know how to debug this further - so far I've examined environment variables, some settings.xml files and searched the windows registry, all to no avail.

By [D-Tail]

Ascended (8261)

02-12-2017, 15:21

Also, I searched for OPENMSX_USER_DATA on the net and in the manual. Only thing that comes up is the github issue tracker. Am I right that this is not noted in the manual?

By Manuel

Ascended (19228)

02-12-2017, 23:01

Indeed, it's not in the manual. Usually it's not needed.

Your Windows system is pretty crippled if applications can't find the home folder... I've never heard this fail either, so this is the first time I hear of this. Perhaps we should make some fallback for situations like this. It is now indeed a fatal error. What would be a good fallback here? Some Windows developers here with advice on that?
The openMSX code is in FileOperations.cc... called from expandTilde, which is called from all over the place.

By ren

Paragon (1930)

02-12-2017, 23:16

Could the following page be of any help perhaps? -> https://superuser.com/questions/432271/keep-programs-from-us...

Somewhat related: I have a disliking when programs add stuff to My Documents. OpenMSX does this as well, while I feel it should use %APPDATA% and %LOCALAPPDATA% for this. What’s the difference between My Documents and Application Data? [MSDN]

By Manuel

Ascended (19228)

02-12-2017, 23:26

Yeah, there's a ticket for that last issue. This code is from a long time ago when AppData didn't exist yet, I think

By the way, openMSX uses CSIDL_PERSONAL... not mentioned in that MS link.

By ren

Paragon (1930)

02-12-2017, 23:23

Ah, cool +1

For reference: openMSX application data location [sf#167] #468