Hello,
according to the log you're missing this file: "P:\Steam\steamapps\common\Arma 3\Launcher\SharedResources.dll". Let Steam check installed files and re-downloaded the missing one:

1. Open Steam;
2. from the Library section, right-click on the game and select Properties from the menu;
3. select the Local files tab and click the "Verify integrity of game cache..." button;
4. Steam will verify the game's files - this process may take several minutes.

Please let me know if this solves your issue.

Hi, Thanks for the reply, It's now working.
Thanks for the help!

Shrugs. My ARMA 3 Launcher still refuses to open. I get no exception. But there is an "arma3.exe" process within the task manager. And all files are verified using Steam.

Looks like I'm looking elsewhere for the problem.

UPDATED: On the flip, just looks like I narrowed the problem down significantly just now.

UPDATED 02:50 AUGUST 01 2015 UTC: Bingo! I have this same apparent exception, "System.IO.FileNotFoundException: Could not load file or assembly 'SharedResources, Version=1.2.131.647, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified." And I believe I know the exact cause of this problem now. Verifying files is likely not the solution, and marking this bug as resolved probably is not correct. I would post the likely cause of the problem and the temporary workaround, but BIS Wizard has yet to reply to his above private messages to myself.

@rogerx, I've already replied to you in the message.

So, now when you are on topic, could you please check that you have the file "(Arma 3 folder)\Launcher\SharedResources.dll" on your hard-drive? Also this library is dependent on other libraries, besided system ones, it's Utils.dll, log4net.dll, SteamLayerWrap.dll and SteamLayer.dll that should be in the same Launcher folder.

Edit: Another thing that startles me is that you have "arma3.exe" listed in running processes. The only way I can think of is that you're deliberately passing -noLauncher parameter to Launcher (through Steam's Launcher Options perhaps?)

Yup. Just updated my information as well. Personally, I think this looks quite unprofessional carrying-on such a conversation above.

$ ls /mnt/windows10/Program\ Files\ \(x86\)/Steam/SteamApps/common/Arma\ 3/Launcher/ -al
total 3.3M
drwxrwxrwx 1 root root 8.0K Jul 28 11:01 ./
drwxrwxrwx 1 root root 8.0K Jul 28 11:01 ../
drwxrwxrwx 1 root root 0 Jul 28 11:01 cs-cz/
drwxrwxrwx 1 root root 0 Jul 28 11:01 de-de/
drwxrwxrwx 1 root root 0 Jul 28 11:01 en-us/
drwxrwxrwx 1 root root 0 Jul 28 11:01 es-es/
drwxrwxrwx 1 root root 0 Jul 28 11:01 fr-fr/
drwxrwxrwx 1 root root 0 Jul 28 11:01 it-it/
drwxrwxrwx 1 root root 0 Jul 28 11:01 pl-pl/
drwxrwxrwx 1 root root 0 Jul 28 11:01 pt-br/
drwxrwxrwx 1 root root 0 Jul 28 11:01 ru-ru/
-rwxrwxrwx 2 root root 144K Jul 28 11:00 SharedResources.dll*
-rwxrwxrwx 2 root root 568K Jul 28 11:00 SteamLayer.dll*
-rwxrwxrwx 2 root root 259K Jul 28 11:00 SteamLayerWrap.dll*
-rwxrwxrwx 1 root root 127K Jul 28 11:00 Utils.dll*
-rwxrwxrwx 2 root root 928K Sep 4 2014 Xceed.Wpf.Toolkit.dll*
-rwxrwxrwx 2 root root 2.7K Sep 6 2014 Xceed.Wpf.Toolkit.txt*
-rwxrwxrwx 1 root root 608K Jul 28 04:11 config.bin*
-rwxrwxrwx 1 root root 294K Oct 25 2014 log4net.dll*
-rwxrwxrwx 1 root root 12K Sep 4 2014 log4net.txt*
-rwxrwxrwx 1 root root 5.1K May 26 18:26 logger.xml*
-rwxrwxrwx 2 root root 12K Jul 28 04:04 notifyicon-wpf.txt*
-rwxrwxrwx 2 root root 193K Sep 6 2014 protobuf-net.dll*
-rwxrwxrwx 2 root root 12K Sep 4 2014 protobuf-net.txt*
-rwxrwxrwx 2 root root 143K Mar 26 18:15 steam_api.dll*

It seems that all the files are in their place. To investigate further, it would be best if you enable a special logger in Microsoft .NET Framework that is design specifically for this.

1. Create a folder "C:\FusionLogs" (if you change a folder you have to update .reg file, see below).
2. Download an archive http://arma.jiripolasek.com/files/Fusion_EnableDisable.zip and run "Fusion_Enable.reg" that is in it.
3. Run Arma 3 Launcher.
4. Compress and upload a content of "C:\FusionLogs" here (there should be 2 folders "Default" and "NativeImage" with HTML reports).
5. Disable the logging by running Fusion_Disable.reg.

This bug seems like an issue with folder and path names within the source code. (ie. Include paths and Include path names.)

I can run the arma3launcher.exe directly under the ARMA 3's program folder. (ie. "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3")

I cannot run the arma3launcher.exe via a desktop shortcut, or the arma3.exe from desktop without Steam running and have the Launcher appear. The arma3.exe process does show active though within the Task Manager. (ie. Likely the system might be looking for the included libraries from c:\Users\roger\desktop instead of the arma3 installed program folder.)

The arma3.exe Desktop Shortcut has the following contents, "arma3.exe4C:\Program Files (x86)\Steam\SteamApps\common\Arma 3h-noSplash -Skipintro -world=empty -noLogs -cpuCount=4 -exthreads=7 -maxMem=32768 -maxVRAM=3712 -enableHT" (I forgot to check for the "-noLauncher" yesterday.)

Like I said, the reason why I think this is a simple programming path name or path location issue, path name or path location bugs are very common here on Linux as well and assume the "Includes (paths)" are within a specific location when the Includes are not. As such, you see the exact problems we're seeing here. (But why is the arma3.exe in the background does sound odd to me. As if the launcher might be appearing on a different monitor/display when all other displays are disabled.)

If you still need further information, such as the Fusion Enable Disable, can I acquire such files and info from microsoft.com?

Sun Aug 2 18:58:58 UTC 2015: Also, I'm setting several loops in some current bugs after my experience with Windows 10. Some features (or bugs) are now working upon initial execution of arma3.exe without having to use the arma3launcher under Windows 10. Whereas in the past with Windows 7, 8, or 8.1, the features required the arma3launcher in order to be detected and work within the 3D world. I likely need to run the arma3.exe and arma3launcher several more times in order to properly dictate what is happening within text.

Mon Aug 3 01:23: Oops. Now that I'm in Windows and looking at going over enabling Microsoft .NET Fusion logging, I see that you're just sending registry settings within a compressed archive. After performing all this manually and verifying with your registry files, I get absolutely no Fusion log files written when running the arma3launcher, whether from the desktop or just clicking on the arma3.exe desktop shortcut with no Steam running. However upon running the arma3launcher.exe from the C:\Program Files (x86)\Steam\SteamApps\common\Arma 3 folder location, Fusion log files are then written within two folders. I think this further cites that something is going on with the Include files not having a global/static search location. (ie. Cannot find Include files within subfolders of C:\Users\roger\Desktop ...) NOTE: Also I already have Microsoft Visual Community installed, albeit regretting it now as it was only a 30 day trial. So I do have fslogvw.exe installed and running.

Mon Aug 3 01:42: I now reproduced the bug with ensuring steam.exe is running in the background and trying to run the arma3launcher from a desktop shortcut. Which spawns this bug's "System.IO.FileNotFoundException: Could not load file or assembly 'SharedResources, ..." bug/exception. With the Fusion logging running as well and then compressed the archive accordingly. (Took the liberty of using 7z compression, as 7-zip seems to run great here.)

What i can tell from those fusion logs, is that you have moved Launcher executable to a different folder (quote from fusion logs: "Running under executable C:\Users\roger\Desktop\Games\arma3launcher.exe") and it can't find libraries, because its config file ("arma3launcher.exe.config") is not in place to tell Launcher to look into the "Launcher" sub-folder for libraries (logs show that when binding libraries for Arma3Launcher.exe and it doesn't check the Launcher subfolder).

For Launcher to work correctly, you need these 3 files and Launcher sub-folder:

• arma3launcher.exe
• arma3launcher.exe.config
• steam_appid.txt

+---Launcher\

• config.bin
• log4net.dll
• log4net.txt
• logger.xml
• notifyicon-wpf.txt
• protobuf-net.dll
• protobuf-net.txt
• SharedResources.dll
• SteamLayer.dll
• SteamLayerWrap.dll
• steam_api.dll
• Utils.dll
• Xceed.Wpf.Toolkit.dll
• Xceed.Wpf.Toolkit.txt
• +---cs-cz\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• +---de-de\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• +---en-us\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• +---es-es\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• +---fr-fr\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• +---it-it\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• +---pl-pl\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• +---pt-br\
• arma3launcher.resources.dll
• sharedresources.resources.dll
• L---ru-ru\ arma3launcher.resources.dll sharedresources.resources.dll

Exactly as I speculated, but I must say, I so much more enjoy the logging/debugging facilities of Linux/Unix versus Windows! All what you just stated, I can see so easily via simple text log files.

The "C:\Users\roger\Desktop\Games\arma3launcher.exe" file is a simply Winodow's shortcut. (Or link file within Linux/Unix.) According to your explanation, the arma3launcher.exe is looking for it's program files within ./ or the immediate folder the program is executed from. The arma3launcher should be programmed to look either within both the immediate folder and "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3" folder, or just statically using "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3". (Forgive my previous confusion, I tend to get AND|OR logic mixed-up easily for some reason after twenty years of programming!)

I get this bug when either using a desktop shortcut, or trying to execute any ARMA 3 desktop shortcut. And further makes sense now as to why all desktop shortcuts fail launching the launcher?

Under the current arma3launcher code, users must either navigate to the "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3" or use the Steam interface to start ARMA 3. (If I'm not mistaken, using the Steam interface still avoids the arma3launcher and immediately executes arma3.exe?) All other methods of execution likely result in the above bug description, or with no debug log file on the desktop but with a backgrounded arma3.exe process, likely in a slave mode awaiting further arma3launcher commands.

The problem is that you don't have a desktop shortcut (in a Windows sense) :) You have a symbolic link and that's all the difference. Those two are not the same on Windows ecosystem.

Then the behavior you describe is completely fine on Windows and confirms to its standards. And for the record, we don't point Launcher to a specific file or path, but we simply specify assembly (DLL file) identity and the file is located based on by standard rules defined by .NET Framework/Windows, which we supplement with an additional hint to include the "Launcher" sub-folder to paths that are considered.

I'm almost absolutely positive I selected "Create Shortcut to desktop" for the executable files within "C:\Program Files (x86)\Steam\SteamApps\common\Arma 3".

Maybe Windows 10 is doing something differently versus Windows 7 or Windows 8.

For verification, I'll go back later and verify that those are shortcuts, but I do believe they are shortcuts, and we do not see this problem with Windows 7 and Windows 8 with the same exact files. (I still have Windows 7 on one partition, with a Windows 8.1 partition upgraded to Windows 10.)

OK, let me know. But beware that both a shortcut and symbolic link have a very similar appearance. E.g. they both have a Shortcut tab in the Properties window.

But a desktop shortcut is a file of type "Shortcut (.lnk)" and has ~ 1.5 kB in size, fields on Shortcut tab are editable and its hidden extension is ".lnk" (the extension always hidden in Windows Explorer regardless your settings, but the extension is visible in command prompt)

The symbolic link has type ".symlink (.exe)", its size is 0 and fields on Shortcut tab not editable and in command prompt it's type is <SYMLINK>.

COPYING EXECUTABLE IS PROBABLY NOT A GOOD IDEA.
This is another reason why I relish the Linux command line console. One cannot screw-up by confusing the two "ln" or "cp" commands when typing. Click and play Windows interface is evidently too easy to perform incorrect actions, I must have copy/pasted the darn program into my desktop games folder.

So this bug is caused by two issues, missing files and missing depends when incorrectly copying the arma3launcher.exe executable to the desktop instead of specifying a shortcut. (Albeit, the later is dumber, but quite easy to do so from within Windows.)

UPDATE: I was just thinking, although upstream and Microsoft's responsibility, within a Linux console symbolic links (or just links) are often highlighted or colored differently within text when compared to other file names. Microsoft should change the gamma color for the icon when they're links. Appending "Short Cut" to the file name isn't the brightest idea, nor is putting a tiny arrow at the bottom corner where the arrow can be easily looked using larger resolution monitors. (And I do have one of the larger resolution monitors where I have to screw with the DPI to get text larger, but icons likely remain the same size.)

APPARENT HANGING OR GHOSTING ARMA3.EXE PROCESSES
After solving this, I'm also finding a separate intermingled bug (or maybe a now planned feature) where the arma3.exe executable cannot be run via either, shortcut or directly. It would appear this is now disabled without steam running in the background prior to executing. The only shortcut to arma3.exe that does work, albeit not a direct shortcut to arma3.exe, is a shortcut pointed towards, "steam://rungameid/107410" Without Steam running, executing arma3.exe directly results in the arma3.exe hung process in the background apparently doing nothing. Once steam is working, executing arma3.exe directly or by shortcuts is then possible. I'm not seeing anything really relevant currently within a bug/feature search results.