Odd Issue with Response Groups and Calls Transfered to RG Causes S4B to Crash on Computer

[John Haverty]

We are using Response Groups in a lot of areas for our work. We had it reported to us that in one popular area where a lot of calls come in from other campus phones that once the call is transferred, the Skype for Business client on the computer crashes. The call continues directly on the phone (Polycom VVX 310), but the Skype client on the computer crashes.

After learning about this issue, I put myself and a few others in a test Response Group so we could test. We were able to duplicate the issue. We applied some Windows updates which then corrected the issue, but with the latest updates from Microsoft, the issue is back.

Curious if anyone else has seen this issue and has a solution. Again, the scenario that causes the issue. Caller X calls Caller Y (Y is campus phone), caller Y transfers to Caller R (response group) to say who they are transferring, Caller Y transfers the call (consultative transfer), Caller R has their Skype for Business app crash on their computer. The call continues, but Caller R has to start up the Skype for Business program again on their computer for that integration.

Below are details we pulled from the last failure when we tried this process. Again, looking for a solution as the area getting these calls is having their Skype for Business app close out on them multiple times a day. It appears to be related to Windows Updates.

Problem signature:

  Problem Event Name: APPCRASH

  Application Name: lync.exe

  Application Version: 16.0.4654.1000

  Application Timestamp: 5a5f2e45

  Fault Module Name: Uc.dll

  Fault Module Version: 16.0.4654.1000

  Fault Module Timestamp: 5a5f36e1

  Exception Code: c0000005

  Exception Offset: 00a22e55

  OS Version: 6.1.7601.2.1.0.256.4

  Locale ID: 1033

Additional information about the problem:

  LCID: 1033

Read our privacy statement online:

  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:  

  C:\Windows\system32\en-US\erofflps.txt

If anyone has any ideas, please let me know.

Thank you!

John

[#2]

MSI or C2R version of Office?
Have you tried to enable logging on the clients to see if you get any more detailed info?
Or enable logging on the server.

[#3]

Alexander,

We are using MSI for our campus installations. I have not tried enabling logging on the client or server at this point. We did apply a Windows update last month and it corrected the issue.... then more updates came out from Microsoft and it stopped working again.

I will check logging on the client to see what we find. I was curious if anyone else has seen this or could test it to see if they can duplicate the problem with the scenario I described.

Thanks!

John

[#4]

We have a similar issue after the latest update, though not related to Response Groups but to Unassigned Numbers instead.

We have an Unassigned Number that transfers the call to an external number. When we dial this Unassigned Number from Skype for Business, lync.exe crashes when the transfer is initiated. Calling from a Common Area Phone works fine though.

Skype for Business on Windows:

• Call unassigned number
• On hold
• Crash

Common Area Phone:

• Call unassigned number
• On hold
• Transfer to destination number
• Ringing

The program lync.exe version 16.0.4666.1000 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.
Process ID: 53e4
Start Time: 01d3cb07db905394
Termination Time: 66
Application Path: C:\Program Files\Microsoft Office\Office16\lync.exe
Report Id: c1e90ceb-db3e-49c4-bfa1-d8dcda1e7c16
Faulting package full name: 
Faulting package-relative application ID: 

[#5]

Stephan,

That does sound similar. We have not checked again after the March Microsoft updates and preparing to release April Microsoft updates, so we will check whether this is happening again. It does appear it worked for a while back in February or so after updates, but then broke with later Microsoft updates.

I am surprised no one else is reporting or seeing this issue. I think it is similar what you describe to what we are seeing. The callers into the response group would be unassigned numbers that call into the response group and then transfer to another assigned number in the university where we see the S4B client on the computer crash; however, the call connects with where we are transferring the call, but the client crashes on the computer.

John

[#6]

This issue is still happening for us. Can anyone else confirm or duplicate this issue with response groups and calls transferred into those response groups from other Skype phones? Again, this was resolved briefly after we applied a Windows Update to the computer (two months or so ago) and then new Windows Updates were released and it was broken again. I would like to have someone else test and attempt to duplicate this issue.

John

[#7]

Hi 

Just wondering if you got this issue resolved

as I've just encountered this very thing 

Thanks 

[#8]

Also having the same problem.  Ticket opened with Tier 2 CSS and not going anywhere.  Any help would be appreciated!

[#9]

Sorry, I missed you had updated until today. No, we have not resolved this issue. It is still happening. I had had it happen to me now too. We recently did S4B updates and Windows server updates thinking this would resolve this issue, but it continues to occur.

John

[#10]

Andrew, no solution on this issue yet that I have heard about. Good to hear others are seeing the issue too. Curious if anyone finds a solution.

[#11]

@John Haverty -- are you guys running the latest CU (July)?

6.0.9319.534

July 2018 (CU7)

[#12]

@Andrew, I believe so. I will have to double check tomorrow. We just did S4B upgrades to our servers in November and Windows Updates. Although, we still have more Windows Updates to complete as we did not get through all of them. I know with this issue, we got it working early on after a Windows update on the end user computer. Then updates came out from Microsoft and it broke again. We have not been able to get it to work since early in this issue.

Odd!

John

[#13]

It really seems like a client side bug, but I manage multiple SfB environments for a dozen or so customers in a product channel. We are NOT able to reproduce in the latest CU. I'm scheduling a change tomorrow (will be implemented by Wednesday night, Thursday morning) to deploy that to this customer environment and will keep you posted.

The weirdest part I noticed though, is that in the affected environment, if we RDP to a workstation from another workstation, it does not happen. This makes me feel like it's a client side bug, possibly in UC.DLL or another library.

I will update again after the change to advise. Thanks!

[#14]

Thanks. I will be interested to hear what you learn. I was debating whether it was a BToE error. If we disable BToE on the computer, we are unable to duplicate the issue. We still have our end user computers running Windows 7 in many areas although we are starting to roll out W10. I am not sure I have had a report of it happening on Windows 10. Not enough using it so far although I do not think I have seen it happen on the Windows 10 box I am using.

[#15]

@John HavertyI don't want to necro an old thread, but we are having exactly the same issue (crash in UC.dll)  at our work.  It seems to happen for us when we get a rapid influx of calls to the response group. 

Did you ever find out if it was BToE that caused it?

[#16]

@syates_pw, we disabled BToE on those computers and the issue seems to have resolved. From what I could tell, it had something to do with BToE and RG's. If BToE is not running, we do not have the issue. The departments have been happy without BToE and S4B not crashing on them.

I know for us, it happened with just one call or multiple calls. Although it was only if the call came into one S4B and then they transferred that call to a person on a RG to the RG. Very odd!

[#17]

We've disabled BtOE for one site and they haven't had any issues since.   

Thanks!

:)