There appears to be a common issue affecting a number of Galaxy S8 users, whereby the person on the other end of a voice call cannot hear any sounds coming from the S8 owner. I was also affected by this issue, and nothing seemed to resolve it (although admittedly I was too hesitant to try a factory reset – given others already claimed this did not resolve it for them).
For me, the issue only occurred when I was connected to my home network. Playing around with relevant WiFi related features, I discovered the issue went away when I disabled Wi-Fi calling.
As with most error messages, this one is not very helpful, simply indicating that a module could not be found. Fortunately this was working on my local workstation, however, the issue was present for test users on their thin client environment, so it was just a matter of finding out what was different between the two environments. After some investigating, I remembered that I had manually added the TRIM client installation directory to the PATH system variable to enable running a web site which uses the HP TRIM SDK. Removing the installation dir from the PATH variable did indeed result in the same error message, and funny enough adding the dir back resolved the issue, on both my local instance and on the thin client instance. I don’t know why the TRIM client install doesn’t just add the TRIM directory to the PATH variable by default. Oversight by HP? I’m sure it used to be… there are also plenty of SDK related forum posts suggesting to add it when starting your application (that doesn’t really help in this instance).
To add the TRIM installation directory to your PATH system variable go to your system settings; (start» type “Edit the system environment variables”) or (start » right-click Computer » Properties » Advanced system settings) » Environment Variables » under System variables locate and selectPath » click Edit » append your TRIM install folder (default TRIM installation directory should be either; C:/Program Files/Hewlett Packard/HP TRIM or; C:/Program Files (x86)/Hewlett Packard/HP TRIM depending on your installation preference.
If you’re using the Microsoft Word integration feature with HP TRIM and receive the error message “Could not load file or assembly ‘HP.HPTRIM.SDK’ or one of its dependencies. The system cannot find the file specified.” chances are you probably have a generic .NET Add-In registered in your TRIM dataset for the record type you’re trying to save your Word document as.
To solve the issue you can copy the HP.HPTRIM.SDK.dll from your Trim installation folder into your Microsoft Office executable folder (e.g. C:/Program Files (x86)/Microsoft Office/Office14 or C:/Program Files/Microsoft Office/Office14 *note your office version may vary e.g. Office11, Office15, etc).
There may be another way to resolve this issue, but so far it’s the easiest and only fix I have worked out.
Recently I was getting the error 0x80030002 STG_E_FILENOTFOUND while trying to run any TRIM 7.3 Outlook Add-In function. The Outlook Add-In had loaded fine and was bringing up all the available TRIM options, it was just when I tried to execute one of the options that it would throw the, oh so very “helpful”, error message as with most COM operations. It wasn’t until I found this thread over in the HP forums that I discovered that Cisco Unified Personal Communicator can interfere with the TRIM Add-In. According to another post, any ODMA integration can cause issues with HP TRIM’s Outlook Add-In, in their case, it was Novell GroupWise causing the issue.
Fortunately for me, Cisco Unified Personal Communicator was no longer required to be installed (and has been replaced by Jabbr – although I did not test if Jabbr causes issues with TRIM’s Add-In), so to resolve the issue I just had to uninstall Cisco Unified Personal Communicator; for good measure I also did a repair of HP TRIM Microsoft runtimes for VS 2008 and a repair of HP TRIM.
Having changed to a 64-bit development machine at work recently I ran into an Oracle error while trying to generate files using CodeSmith. This error was ORA-06413: Connection Not Open. Assuming it was a connection string error, as I had not run this particular generation in some time and it was likely that the server or username/password had changed, I proceeded to test the connection from SQL Developer. Success!
After ruling out that the connection was indeed valid I did a quick Google search for the error message. After a few clicks I discovered a very well known (has been around for a few years) Oracle issue; When executing an Oracle command from an application with parentheses or equals — ‘(‘ or ’)’ or ‘=’ — in the path than the specified error message is thrown.
In this particular case, CodeSmith had been installed under C:/Program Files (x86)/CodeSmith which was causing Oracle to fail. The quickest workaround was to simply move CodeSmith from the Program Files (x86) path e.g. into C:/CodeSmith. However; there is a patch (5383042) for Oracle 10g, which is also applied to Oracle 11G.