03-05-2013 08:43 AM - edited 03-16-2019 04:04 PM
Hello,
Already search but didn't find anything related to this issue/bug.
I'm having this issue with one IP Communicator in one of our remote sites.
The phone was working fine and sundly got a black screen.
I already unistall and install the CIPC but still with same error. It is running windows 7. It can ping call manager without any problem.
All other phones on that site are fine.
Any idea on how to solve this issue?
Thanks,
Chris
10-06-2020 08:36 AM
This helped ****EXCEPT**** I did not delete the actual keys. I deleted the bloated entries within the keys. BUT I left the first value of each key. I DID NOT DELETE THE KEYS, JUST THE ENTRIES.
These keys had 100's of entries which I think was causing the black screen:
device.calls.placed
device.calls.received
device.calls.missed
05-20-2016 08:47 AM
Hi Paul,
I had the same issue once, I've found out that my CIPC had an issue interracting with my Jabra headset, once I disconnected the headset the CIPC booted normally.
I hope my comment will help you, Paul.
Regards,
05-25-2016 02:54 PM
I understand that this is an old post, but as there are basically no other results for this black screen issue I figured I'd share what we just learned about this recently. Skip to the end for solution.
In our environment, the black screen was ultimately being caused by a permissions error, but one that was not readily apparent. The traces were showing a number of access denied errors at the root of our profile store that looked something like this:
java.io.FileNotFoundException: \\contoso.com\DfsRoot\users$\%FILE.EXT% (Access is denied)
Now, this made no sense to me. Why is it trying to save files to the root of the profile share? I started looking through ProcMon results and found similar errors. I compared against the ProcMon results for a working user and think I've worked out what's happening.
Problematic User:
CreateFile || \\contoso.com\DfsRoot\Users$ || NAME NOT FOUND || Disposition: Open
Working User:
CreateFile || \\contoso.com\DfsRoot\Users$ || SUCCESS || Disposition: Open
QueryDirectory || \\contoso.com\DfsRoot\Users$\username || SUCCESS
...
From this I gathered that the issue was being caused because communicator couldn't open the user share in order to check for the existence of the user's profile folder. I suspect that it was then failing to append the path for the user's roaming app data to the root file path above.
Resolution:
Granted Creator Owner full access to subfolder and files at the root of the profile share.
Granted Everyone Read access to the root of the profile share (but not to subfolders).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide