The problem with "QSettings: RegEnumValue failed" is not fonts

So, I was looking at that monster thread (Help! Downloaded update now Scrivener won’t load) about how certain fonts caused the startup of Scrivener to fail. My symptoms matched those of WrittenHard (log shows fonts loading, a few “No PostScript name” messages, followed by repeated “RegEnumValue failed” messages).

Following the posts in this thread, I was experimenting to see which fonts might be causing my problem. Turns out, the problem has nothing to do with fonts.

Since I was getting “QSettings: RegEnumValue failed:” in my –log output, I did a google search to find out what code might produce that message. That found me this:

cep.xray.aps.anl.gov/software/qt … ource.html

This may not be the exact source file Scrivener is using, but given the (unusual) error string, and the fact that this code has the same problem as Scrivener, I’ll bet it’s close.

In short, childKeysOrGroups() is trying to return a list of all the subkeys of a specified registry key. It does this by calling RegQueryInfoKey to get the number of subkeys, then it performs a loop calling RegEnumKeyEx, passing the loop value as the index number to retrieve. If it encounters a problem, it logs this ‘QSettings’ message.

Because of what appears to be a bug in Windows, this approach for reading subkeys doesn’t work correctly. Put simply, RegQueryInfoKey isn’t consistently returning the correct count of subkeys. It often returns values in the tens of millions, when the correct answer is actually 2 (suggesting Scrivener would start… eventually).

I can see at least 2 different ways to fix this:

  1. The RegQueryInfoKey function takes a number of parameters for values it can return. If you don’t need a particular value, you can just pass NULL. However for some reason, if you don’t retrieve the value for the 7th parameter (lpcMaxClassLen), the number of subkeys returned is unreliable. Obviously you don’t need to use the returned value, but apparently you must ask for it.

Note: This bug doesn’t affect every key. But clearly it affects HKEY_CURRENT_USER\Software\Classes\CLSID (or more accurately HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID since I am on x64 and Scrivener is a 32bit app), which is one you are using.

  1. The registry is basically a database, and any application running on the computer might be adding or removing keys at any time. Getting a ‘count’ and then walking ‘count’ keys runs the risk of someone having make a change between the two operations. A (slightly) better approach is simply to keep calling RegEnumKeyEx, incrementing the requested index until ERROR_NO_MORE_ITEMS is returned.

My test code showing the bug in RegQueryInfoKey is available upon request.

FWIW

PS My next goal is to report this to MS. Wish me luck.

FWIW, I was able to load and use Scrivener by simply making a new user on my Windows box. This is definitely in the user profile on Windows, not sure if it is a file or registry error, however.

Do you still have the profile that fails? I was trying to track it down, but it doesn’t fail for me anymore.

I don’t suppose you use VirtualBox?

Yes, I still have the profile. No, I don’t use VirtualBox.

Response to this issue so disappointing. Making new user profiles is hardly something anyone should have to do, and more than visiting forums every few weeks to check on solutions is.

Seems to have dropped off the radar. We’re nearly six months after last update, and I’m writing in Notepad when on my desktop machine.

If you are feeling brave, you can attempt a test. Note that this test is ONLY useful if you have run “Scrivener.exe --log” and seen repeated “RegEnumValue failed” errors getting logged. Do NOT attempt this test for any other Scrivener problem, as there is a risk that this will cause problems with products other than Scrivener.

It should probably go without saying, but I’m going to say it anyway: When making changes to your system that are proposed by anonymous guys on the internet, use at your own risk.

  1. If you don’t already know, figure out whether you are running 32bit or 64bit Windows.
  2. Launch RegEdit (if you don’t already know how, this test may not be something you should try).
    3a) If you are running 64bit Windows, look for HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID
    3b) If you are running 32bit Windows, look for HKEY_CURRENT_USER\Software\Classes\CLSID
  3. Make ABSOLUTELY CERTAIN you are looking at “HKEY_CURRENT_USER”, not “HKEY_LOCAL_MACHINE”. Editing HKEY_LOCAL_MACHINE (or some other key that is “kinda like” what I list here) would be VERY, VERY BAD (like “trash your computer” bad). If you are at all unsure (or cannot find the EXACT key described), do not proceed.
  4. Use Edit/Rename to rename the CLSID key to ScrivenerTest.
  5. Try to launch Scrivener.
  6. Whether the launch succeeds or fails, immediately return to RegEdit and rename the ScrivenerTest key back to CLSID before doing anything else. Be careful you don’t add a space after CLSID (easy to do if using copy/paste).

Let me emphasize this: Even though this might fix your Scrivener problem, do NOT leave this key renamed. There’s no way to know what all is using that key. But whoever it is, they will be unhappy if it is missing, and there’s no telling what bad things might happen as a result.

If you attempt this test, here are the things to report:

  1. Did you run the “Scrivener --log” test and see the “RegEnumValue failed” message?
  2. Did your computer have the exact CLSID key described in steps 3a/b?
  3. Did Scrivener successfully launch after you renamed the key?
  4. What version of Windows (7? 10?) are you running? 64bit or 32bit?
  5. Are you (like me) running any of the Tortoise* tools for software version control (TortoiseSvn, TortoiseCvs, TortoiseGit, etc)?

What this will tell us:

The problem here probably isn’t due to any of the programs that use that registry key (although it might be, which is why I’m asking about Tortoise). Collecting a list of installed programs we have in common might be interesting.

But mostly what I expect to learn is that everyone who is getting this QSettings message has this key. The key is not always created (or needed), which is why creating a new profile works for some people: The new profile doesn’t have this key.

However if (as I expect) renaming this key solves the problem for people, then L&L will have an easy fix they can apply to their software (fixing their copy of the QT toolkit as I described at the top of this thread). If the L&L people are uncomfortable making the change, I can post a corrected copy of the childKeysOrGroups routine (but you’ll still have to rebuild the QT library yourselves).

Unfortunately I can no longer run this test myself, since Scrivener is no longer failing to launch on my machine. Darn the luck…

Have you emailed L&L tech support directly? I recommend that approach if your issue hasn’t been resolved.

https://www.literatureandlatte.com/support.php

I was feeling brave and taking all due precautions. :smiley:

This is definitely where the issue lies. I followed your instructions here except I renamed my CLSID key to “CLSID-old”, closed regedit and started Scrivener with the log function. Scrivener launched properly. I closed Scrivener and reopened regedit to find I had a new CLSID key with the Scrivener specific key in it. See screen shots. Process ID name of the Scrivener key is: Rnvrcs and appears to have the same data.

The other CLSID keys were easy to figure out and did not seem to bother the operation of the PC or software.
FWIW: msdn.microsoft.com/en-us/librar … 53(v=vs.85.aspx

  1. Yes, no on the error message.
  2. Yes for 3A.
  3. Yes.
  4. Windows 7 64-bit SP1 (fully patched).
  5. No, not on this machine or on a machine with Scrivener installed.

I can make Scrivener break on that user by swapping the CLSID key names. It might be interesting to make a copy and then remove the other software CLSID entries to see if one of them fixes the Scrivener key; however, I think that it won’t make much of a difference. The only two keys I have found between the two users that are common are both for Grammarly:

HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID{2AD206F1-152C-4F9D-A24E-6F93FE7A4AFC}

  • and -
    HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID{4BE56754-B616-4998-B825-D16983AEE1B2}

In my working Scrivener user, those two keys are present. In my previously non-functional Scrivener user they were there, but not in the new functional version of CLSID. Grammarly does work properly for the user without those two keys.


You say that scrivener is creating a registry key for Rnvrcs.dll. I’m seeing that too. However what I don’t see is a file named Rnvrcs.dll anywhere on my computer. Googling for this file and the associated clsid all seem to relate to malware.

Do you actually have an rnvrcs.dll file?

No, I do not have that file. In following the alleged malware links, it seems that those asking for help have Scrivener installed but a malware infection elsewhere. Nobody seems to know what the rnvrcs.dll is, and I can’t figure out why it would be called for in the registry if the file does not exist. I (we) can only assume that it is Scrivener-related due to two things: 1) the key is created the first time Scrivener starts, 2) in the key sub-key ProgID the data shows Rnvrcs-1.9.7.0 which is the same version number of Scrivener for Windows.

I’m afraid that without looking at the code for Scrivener for Windows or one of the developers chimes in with an explanation, we have hit a dead-end. Seeing as how my Scrivener is working properly, I have pretty much given up trying to figure out why it ever stopped working. I’m now about 30,000 words into my book and need to concentrate on that to meet my deadline. I’ll keep following the thread here, but probably won’t be very active for awhile.

  1. Did you run the “Scrivener --log” test and see the “RegEnumValue failed” message?
    Yes, no message.
  2. Did your computer have the exact CLSID key described in steps 3a/b?
    Yes.
  3. Did Scrivener successfully launch after you renamed the key?
    No. Seems to have opened a process in the background that I had to close before reverting (again) back to the older version. But that was happening before.
  4. What version of Windows (7? 10?) are you running? 64bit or 32bit?
    10, 64 bit.
  5. Are you (like me) running any of the Tortoise* tools for software version control (TortoiseSvn, TortoiseCvs, TortoiseGit, etc)?
    No.

Regular virus and malware scans are run. I don’t think it’s ever picked anything more than a few cookies up. And I don’t have the file, either.

:frowning:

I also experienced the same problem. :frowning:

Honestly, at this point, I can only conclude that the company just doesn’t care.

Or that so few users (those posting here are obviously self-selecting) overall are experiencing the issue that limited developer resources are better spent elsewhere (beta 3)?

Or that the base problem lies within the Qt4 framework Scrivener 1.x uses, there is nothing they can do to fix it, so they are focusing on getting beta 3 (running on Qt5) to a release state?

I’m not so sure they don’t care so much as they are busy working on the Beta version 3 and don’t have the resources to fix this issue if it is not so much a complete stop for people to be able to use Scrivener (not a widespread bug), and seems to have a number of ways to correct it (see above for the registry hack I used). I’ve not had the issue reappear even though I have changed computers a couple of times since my initial problem.

I’ve seen quite a lot of people mention the issue, actually. And few or not, we’re still paying customers. If security holes ever need plugging, we’re kind of screwed. It’s not like we’re all just sitting here waiting, either. I’ve tried every potential method I’ve seen, plus everything else I can think of and nothing has fixed it. Others might not be confident enough to go digging around in their registries, or they might not have the time - I don’t either, but every now and then I’ll try updating to the latest version again and give it another go. But all it ever seems to do is waste time that we could be spending writing.

It might be a small team, but if fixing basic features is always set aside for the next big, shiny feature or version, then it’s never going to be fixed. If they have finally identified the problem, then great. - But what about those affected by the bug currently? Are we going to have to pay for a whole new license when the one we’ve already paid for is broken? After, what, two years? with no fix and very little information, I have no reason to believe that they won’t do exactly the same thing with similar bugs in future versions. For several months of that, they quite literally forgot about it. I’m sorry, but I’m not willing to hand over any more money until I can be sure that it’s not wasted.

It might seem overly negative to some, but there is a good reason for it.

I just updated Scrivener to 1.9.9.0 on my Windows 7 (64-bit) computer and the program worked only once before succumbing to this bug. The trick of renaming CLSID works, but that’s a bit of a hassle not to mention risky…