Currently we are updating our desktops to Windows 10. Any of the Desktops that have updated to windows 10 are giving an error message of "failure to acquire image" when trying to use the camera. We have tried adjusting the security settings, updated the drivers and are currently waiting on a response back from Athena/GE to get any more information in relation to this issue. Wanting to know if anyone else with Windows 1o is having this issue and if there is another way to resolve it?
Thank you for any information regarding this issue and helping to solve it.
We had the same issue and had to resort to using the camera's native software to take a picture and then import the file instead of acquiring directly. Would be very interested to hear if anyone has a USB camera that will work properly with Centricity when running Windows 10.
Yeah we have encountered this before and here is a solution for it.
When logged on to the machine as a standard user and attempting to capture an image in the EMR, you receive the message “Failed to acquire image from device” after clicking on Take Snapshot.
When capturing the events on the PC using ProcMon, you will also see the following event:
The two important pieces of information in the screenshot above are the “Result – ACCESS DENIED” and “Integrity – S-1-16-8192”. When the EMR attempts to capture a photo it utilizes the file capture.avi that is located in the root of the C:\. The user account we are using is a standard user account, and the default NTFS permissions do not allow standard users to modify the root of the C:\, resulting in receiving g Access Denied. However even after granting the user “Modify” permissions on the file you will continue to receive this same entry in ProcMon indicating “Access Denied”. The reason for this is because of the information in the Integrity column. The integrity column is only applicable for local file/registry access on Vista or higher when User Account Control (UAC) is enabled. (In this example we ran ProcMon on a Windows 8 machine, which resulted in an integrity of S-1-16-8192. This value is the equivalent of “Medium” – see here http://support.microsoft.com/KB/243330 .) Users in the “Authenticated Users” group are able to execute items at a Medium mandatory level. To view the integrity of the file C:\capture.avi we can use the tool icacls.exe. Open an elevated command prompt and run the following command – icacls c:\capture.avi
The last line of the output indicates the file currently possesses a “High Mandatory Level”. Therefore, in the files current state, a user will need to be in the local Administrators, Backup Operators, or Network Configuration Operators security groups (more information here http://msdn.microsoft.com/en-us/library/bb625963.aspx ). However, using icacls, it is better to change the file to a Medium Mandatory Level. To do this, execute the following command - icacls c:\capture.avi /setintegritylevel M
We can then execute icacls c:\capture.avi again to confirm our changes have been applied.
Now when attempting to capture an image in the EMR you should no longer receive the error message and you can successfully acquire the photo (indicated by the button Attach being available).
Awesome post dude!
Thanks! Took me a little bit to figure this out but it has worked for us from I believe EMR 9.5 - 9.12. I know you are not the original poster but doing this for the staff that need it should save them the hassle of needing to use the camera software, then importing the file later. If you encounter any issues with it just let me know. We install the EMR through a PowerShell script have this solution built into the process. So far this has worked for us on Windows 7, Windows 10, and Windows Server 2012 R2.
Great information, thanks for this post. Support has never been helpful with this and just dismiss it as "we can't control how all the webcams work, and we also can't recommend any specific camera."
We had the same problem, and resorted to making camera users local Administrators on the PC, which I hate doing. We still get the errors occasionally for unknown reasons, but it doesn't last forever usually. I like this solution much better so I hope to get a chance to try it.
You don't happen to know how to resolve the register DLL problem with CEMR and CPS 12.3.3 on the same workstation, where every sign in shows a popup error message? Support says the only solution is to make every user a local Administrator on the PC.
Thanks!
Wade
After installing CPS, we have always launched CPS as an administrator because of the DLL installation for IE. Once that is done, you can launch it with no issues for non-administrator accounts on the same machine.
Hi Tony,
Do you use CPS only, or CPS+CEMR? We are able to resolve the DLL issue temporarily for CEMR or CPS by registering the appropriate DLL as an administrator. The problem we haven't been able to resolve is that we can register the DLL for either CPS or CEMR, but then the next launch of the other one will get the error. We haven't been able to get the error to go away permanently, we have to "pick" which software we want to show the error. Is that the same problem you're talking about, or are you talking about fixing it for only CPS?
Thanks,
Wade
Sorry, didn't realize you weren't on the combined product.
I don't have a solution for the EMR/CPS being installed on the same machine but we suffer from it as well. We were told by support to either make everyone a local admin or do not install CPS/EMR on the same workstation. We use published desktops on Citrix XenApp so both suggestions were out of the question. Since the DLL is tied to the messaging tab we needed it to work for the EMR and not for CPS. Our solution at the moment is to have a task running every 5 minutes to re-register the EMR DLL on all Citrix servers. The reason for this is we found if someone administratively logs in to one of the Citrix servers and opens CPS, the CPS DLL file will re-register and also unregister the EMR DLL. Therefore, the 5 minutes recurring task is there to avoid this "whoopsie" moment.
Thanks for the extra information about the DLL registration on CEMR+CPS. When you say it's used by the Messaging Tab, where do you mean exactly? We haven't noticed any ill effects from the error, which makes me think it's a feature we might not use.
Thanks,
Wade
What I am referring to is the "Messaging" tab in the EMR to access the Kryptiq secure email. There is a DLL file for both CPS and EMR that can be registered to make this tab available. The file for CPS is "C:\Program Files (x86)\Centricity Practice Solution\Client\GE.EMR.CPS.Msg.IF.dll" and the file for the EMR is "C:\Program Files (x86)\Centricity EMR\GE.EMR.Msg.IF.dll". During installation of CPS and the EMR they will register their associated DLL file for messaging. The problem is when both CPS and EMR are installed on the same workstation. If you register the DLL file for CPS, it will remove the registration for the EMR. When this happens, staff logging into the EMR will then receive an error message like this and the "Messaging" tab will not be available:
You can resolve this error message by either launching the EMR as Administrator or manually registering the DLL file, but then I receive this error message when logging into CPS:
Since we use Messaging in the EMR we needed to make sure the EMR DLL was registered. This is why we created the scheduled task to re-register the DLL file every 5 minutes to make sure this is the "active" DLL.
In our environment we have always installed CPS first and then the EMR because of this however with the upgrade to CPS 12.3 and/or EMR 9.12 it introduced the error message appearing in CPS if the file is not registered. Prior to upgrading to CPS 12.3 and EMR 9.12 we were on CPS 11.1 and EMR 9.8 so I don't know which version it was introduced in. I have worked with support and their suggestion was to either make all users local Administrators or do not install CPS and EMR on the same machines. We would never make all users local Admins and we use Citrix XenApp with published desktops so separating the applications would not work for us. They have acknowledged this error and is on the list for potentially fixing in version 19. Time will tell!