Fix for failure to launch LOTRO client application with WINE

[Tralfazz]

Back in October of 2022, someone told me that they were having trouble running LOTRO with WINE. Using a simple dock icon made from the LotroLauncher.exe file, they were able to launch the LOTRO Launcher application successfully, but after entering their credentials and choosing a server and clicking PLAY, the client would start with a black screen and go nowhere. However, when running the game by using the "wine */LotroLauncher.exe" Terminal command (with the actual full path to the file rather than the * wildcard symbol) the client would launch successfully. A number of other people have reported this issue since then. This didn't make a lot of sense to me but I have been working on a solution ever since.

By creating multiple test systems I was finally able to replicate the problem. And by carefully following the execution traces, I learned what was causing the problem: The LOTRO client application did not have permission to use the microphone. When first launching the game with the Terminal, a popup appears asking the user to give permission to access the microphone. Because the active application is the Terminal – not anything related to WINE or LOTRO – the active application which receives that permission is the Terminal. When the LOTRO client is first launched by double-clicking the LotroLauncher.exe file or clicking on a Dock icon made from that file, the active application is Wine X (such as Wine Stable, Wine Devel, etc.) – sometimes the popup will appear and sometimes it won't. If it appears, no problem, the game will run and you will have no issues in the future. But if the popup doesn't appear, the Wine X application doesn't receive the permission it needs to access the Mac's microphone and so the LOTRO client does not successfully launch past a black screen. And once that happens, no matter how many times you attempt to launch the game again, you will never get that popup. If the user goes into System Preferences->Security & Privacy->Microphone there is no way to add an application to the list, permission can be granted or denied only to applications which have been registered as requesting that permission.

I have come up with a workaround for this. It's a teeny bit complicated to read about but is easier to do than it seems:
1- Go to ~/Library/Application Support and make a copy of the com.apple.TCC file. Just option-drag a copy to your ~/Desktop or some other convenient location. You shouldn't need this backup but we are going to make changes to this file so just in case something goes wrong, you will have a backup ready.
2- Be sure that System Preferences is not running.
3- To find the exact system name of the Wine application in your /Applications folder (be it Wine Stable, Wine Devel, Wine Crossover, or any other variant), go to your /Applications folder and look for the Wine application. Right-click on it and choose to SHOW PACKAGE CONTENTS. Click on the CONTENTS folder. Open the info.plist file with TextEdit. Look for the line with CFBundleIdentifier, the line directly under that is the system name of the application. Copy that name to the clipboard, then close the file and quit out of TextEdit.
4- Launch the Terminal.
5- Type each of these lines, one at a time, hit the RETURN key after entering each line:

sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db

insert into access

values

('kTCCServiceMicrophone','PUTEXACTNAMEHERE-SEEABOVE', 0, 2, 2, 1, null, null, null, 'UNUSED', null, null, 1669648527);

.quit

VERY IMPORTANT: Where you see PUTEXACTNAMEHERE-SEEABOVE you must enter the "CFBundleIdentifier" which is the name and ID of the application as MacOS sees it. For example, I was running my tests with a specific version of WINE called Wine Crossover, and that is the name of the Wine application in my /Applications folder. I needed to input the following in place of PUTEXACTNAMEHERE-SEEABOVE:

org.winehq.wine-crossover.wine

The line I used, therefore, was:

('kTCCServiceMicrophone','org.winehq.wine-crossover.wine', 0, 2, 2, 1, null, null, null, 'UNUSED', null, null, 1669648527);

6- Launch System Preferences, go to Security & Privacy, go to Microphone. You should see your Wine application in the list and it should be checked on, i.e. have permission granted to use the microphone. After you confirm this, quit out of System Preferences.

The game will now launch normally from the Dock or by directly double-clicking on the LotroLauncher.exe file.

If for any reason this didn't work for you, or you made some error which screwed up your Microphone permissions in some way; simply take your backup of the com.apple.TCC file and drop it into ~/Library/Application Support, allowing it to overwrite the screwed-up version there. Then either start over and try again, or come to this thread and I'll help you.

[Echoweaver]

If for any reason this didn't work for you, or you made some error which screwed up your Microphone permissions in some way; simply take your backup of the com.apple.TCC file and drop it into ~/Library/Application Support, allowing it to overwrite the screwed-up version there. Then either start over and try again, or come to this thread and I'll help you.

for me, this command:

sudo sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db

produces this error:

unable to open database file.


This is true even when I use sudo. What am I missing?

I'm not 100% sure that this is the same problem I have, but it seems plausible. I don't see a black screen. As far as I can tell, nothing happens after I attempt to launch from the launcher. Everything runs fine under Crossover 21. I'm keeping both the most recent CrossOver and CrossOver21 so that I can continue to run LOTRO.

[Tralfazz]

for me, this command:

sudo sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db

produces this error:

unable to open database file.

This is true even when I use sudo. What am I missing?

The sudo prefix isn't necessary although it shouldn't hurt anything, either.

Did you type the line yourself or copy-paste? If the former, try the latter, because spacing and exact keyboard characters are necessary for this to run.

If you didn't have sqlite3 installed you would have received, "command not found: sqlite3" so that's not the problem. I know that even something as old as MacOS 10.14 Mojave comes with sqlite3 rather than some older version or nothing.

What happens if you just enter "sqlite3" into the Terminal? You should get this output, with a different timestamp and possibly a slightly different point release of sqlite3:

SQLite version 3.39.5 2022-10-14 20:58:05
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.

Then use the ".quit" command to exit from sqlite3.

When you go to System Preferences/System Settings->Security & Privacy->Microphone, do you see Crossover listed? If it is listed but disabled, enable it. There's no need to patch the database file if you can change the setting in System Preferences/System Settings.

When you look inside ~/Library/Application Support, do you see a com.apple.TCC folder? If so, do you see a TCC.db file in the com.apple.TCC folder? If that folder and file are there, one possibility is that you are entering the path name incorrectly – copy/paste rather than manually typing should fix you right up in that case.

However, it is also possible that SIP (System Integrity Protection) is preventing sqlite3 from accessing the permissions database. This is most likely if you are running MacOS 10.15 Catalina but could happen in other versions of MacOS. SIP can be disabled but I don't recommend doing so just to attempt this manual permissions database editing procedure because I am fairly confident it is not going to help your specific case; see below.

I'm not 100% sure that this is the same problem I have, but it seems plausible. I don't see a black screen. As far as I can tell, nothing happens after I attempt to launch from the launcher. Everything runs fine under Crossover 21. I'm keeping both the most recent CrossOver and CrossOver21 so that I can continue to run LOTRO.

So you can launch the LOTRO client with Crossover 21 but not with Crossover 22. Yes, I remember you reporting that some months ago.

There are several possible permissions issues but lack of microphone access seems to be the one that most commonly prevents the client from launching with open-source WINE. It is not impossible that this is the issue preventing Crossover 22 from launching for you. If you are attempting the procedure in Message #1 of this thread, the CFBundleIdentifier for Crossover 22 is:
com.codeweavers.CrossOver
I'm not 100% certain because I can't check it right now, but I think that it's the same CFBundleIdentifier for Crossover 21. Which means any permissions granted to Crossover 21 will also be applied to Crossover 22. If that's the case, which is extremely likely, then it is not a permissions issue which is preventing you from launching the LOTRO client with Crossover 22. And therefore the procedure for granting microphone access to the Crossover application by editing the database file will have no effect for you.

I'm sorry to hear that you're continuing to have issues with Crossover 22 and LOTRO. I am not experiencing this issue, however you are not alone in reporting this specific problem. There are people on the Codeweavers forums who are continuing to report issues with other Windows applications which ran fine in Crossover 21 but will not launch in Crossover 22 – for them, because in most cases other people report that they can get those same applications to run in Crossover 22. I can't be sure because very few people who report such things provide very much detail, such as their exact Mac model or the version of MacOS they are running. However, I suspect that in most cases these people are not running MacOS 13 Ventura and so I wonder if you might try:
–creating a new APFS volume on your MacBook
–installing Ventura onto it
–installing Crossover 22 onto that
–creating a new Windows 10 64-bit bottle
–installing DirectX for Modern Games into the bottle
–using "Run Command..." to attempt to launch LOTRO (by running the */LotroLauncher.exe file in your existing LOTRO bottle on your Catalina boot volume).
That last step will save you the time and hassle of redownloading/installing LOTRO in the new bottle, or futzing around trying to use the Finder to copy it into your new bottle on the Ventura boot volume from the existing bottle on your Catalina boot volume. Just an experiment, more for my benefit than yours since I understand you prefer to stick with Catalina anyway. It would be interesting to learn the result, however, and perhaps you share that curiosity.

[Echoweaver]

I'm not 100% certain because I can't check it right now, but I think that it's the same CFBundleIdentifier for Crossover 21. Which means any permissions granted to Crossover 21 will also be applied to Crossover 22. If that's the case, which is extremely likely, then it is not a permissions issue which is preventing you from launching the LOTRO client with Crossover 22. And therefore the procedure for granting microphone access to the Crossover application by editing the database file will have no effect for you.

All your analysis of 21 vs 22 is correct. My problem is not microphone permissions. After I posted here, I checked System Preferences, which I should have done first. Permissions for the microphone are already granted to CrossOver.

However, it is also possible that SIP (System Integrity Protection) is preventing sqlite3 from accessing the permissions database. This is most likely if you are running MacOS 10.15 Catalina but could happen in other versions of MacOS. SIP can be disabled but I don't recommend doing so just to attempt this manual permissions database editing procedure because I am fairly confident it is not going to help your specific case; see below.

This may be the issue. I do have sqlite3. I can run it just fine. I can run it from the command line. I can "ls" the db file at its path, so I know the path is correct. But if I attempt to open the file with sqlite, whether on the command line or inside sqlite itself, I get that error. I'll stop caring unless I need to do something else with it.

You did actually convince me to upgrade from Catalina. Unfortunately, the upgrade did not go smoothly, which is an off-topic rant. I'm going to make another attempt soon, but I'm fiddling with my backups first. So I guess for the medium-term, we should assume I'm staying on Catalina. It's true that I'd rather avoid Ventura for a while longer because I understand that it drops Rosetta support. My goal is Monterey.

I'm sorry to hear that you're continuing to have issues with Crossover 22 and LOTRO. I am not experiencing this issue, however you are not alone in reporting this specific problem. There are people on the Codeweavers forums who are continuing to report issues with other Windows applications which ran fine in Crossover 21 but will not launch in Crossover 22 – for them, because in most cases other people report that they can get those same applications to run in Crossover 22. I can't be sure because very few people who report such things provide very much detail, such as their exact Mac model or the version of MacOS they are running. However, I suspect that in most cases these people are not running MacOS 13 Ventura and so I wonder if you might try...

I'll see what I can do here. It's sort-of good to know that I'm not the only one reporting weirdness. Too bad it's not enough people to get a reproducible problem. I'll see about fiddling around with a Ventura partition. In theory, my backup insecurity should be resolved in another week or so, and which point I'll take another stab at upgrading the OS to something more likely to match what others are using.

[Tralfazz]

Thanks for the detailed reply!

Ventura has Rosetta2, just as Monterey and Big Sur do. Rosetta2 is the Intel->ARM translation layer. I don’t think Rosetta2 is going away this decade. It’s only an issue for Apple SOC/ARM Macs (currently the M1 and M2 machines), you do not have nor do you have any use for Rosetta2 in Catalina. Unlike Rosetta (the PowerPC->Intel translation layer), Rosetta2 is an Apple product, not a licensed product from a third party. Apple dropped old Rosetta beginning with 10.7 Lion because they didn’t want to pay royalties and that’s a big reason why every OS upgrade since then has been free.

Perhaps you meant something other than Rosetta? If you meant 32-bit support, that was dropped after 10.14 Mojave. Again, you’ve been on Catalina for a long time so you already don’t have the ability to run old 32-bit bit Mac applications. Unless you’re thinking of something else, I don’t think there is a specific capability or technology you’re going to lose by going to Ventura. That doesn’t mean there may not be some software incompatibilities, that’s why it’s a good idea to set up a test volume to try out a major new OS (especially if that new OS is 3 upgrades past your current OS) before applying the new OS as an update to your current boot volume.

edit: 32-bit support is why I keep a boot volume with MacOS 10.14 Mojave ready to go on my main workstation (a 2019 21.5" iMac). There are a couple of games that I own which are 32-bit and have never and will never be upgraded to 64-bit. They are all available as Windows applications and can (probably) run in Crossover but I don't want to purchase them again because, to be honest, I may never play them again and if I do it won't be very much. More importantly, there are two 32-bit Mac applications which I use for business which are never going to get a 64-bit Mac version and have no Windows counterparts so I reboot to Mojave when I need to use them – which is very, very rarely nowadays. I could replace them with a couple of close-enough modern applications but I am a cheapskate so... until I can't use them because I get rid of all my Macs that can boot Mojave, I'll probably keep using them. 9/10 times I reboot to Mojave for the last 2.5 years it's been to test something related to LOTRO rather than for anything else, though. If I weren't playing LOTRO, or even if I were but if I weren't trying to help people with older systems here in the Mac Technical Support forum, I'd probably get rid of it. After archiving the contents, of course! But mainly for the games, even through I don't know if I'll ever play them again.