cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
25362
Views
20
Helpful
17
Replies

IP Communicator Black Screen

Paul Zon
Level 1
Level 1

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

17 Replies 17

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

amine..dahel
Level 1
Level 1

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,

lucas.jereska
Level 1
Level 1

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).