• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 700
  • Last Modified:

Applet calls to dll result in 100% CPU utilization in a Citrix environment

We have a java based application that runs as an applet in internet explorer.    One of the things that this applet does is load a dll that is used to launch a third party piece of software.   One of our clients has deployed our application in a Citrix environment.   Only with  this client, (who is also the only one running Citrix) do we see a problem where, intermittently, CPU spikes on the Citrix server to 100%.    When we use process explorer to see what is happening, I see that the culprit is MSVCR71.dll.   How do I solve this problem?    
0
efamilant
Asked:
efamilant
  • 7
  • 6
1 Solution
 
sarabandeCommented:
100% cpu normally means an infinite loop without sleeps.

while (anycondition())
{
    i++;
}

Open in new window


you should check whether on the non-citrix environments you don't have always a multi-core cpu where one of the cores also always runs at 100%.

the msvcr71.dll contains runtime extension of the vc7.1 (comes with VS2003) . i don't think the loop is inside of that dll but that one of the functions in the dll was called in a loop without sleep. in my sample the call to vc runtime would be in the anycondition().

i would say you can't solve the problem when the third party won't help you. the only thing you could try yourself is to update both internet explorer and .NET in that environment to the newest possible. that rarely would help from the loop but could speed up the final break of the loop.

Sara
0
 
efamilantAuthor Commented:
This is not likely the cause.     There are no loops like this in the code.
0
 
sarabandeCommented:
didn't you say it is a third-party code?

the endless loop not necesserily must be as simple. it could be any loop or recursive call without a sleep or wait function. then it would push the cpu to 100% until the break condition was reached.

Sara
0
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

 
efamilantAuthor Commented:
This is a widely used dll and it is deployed in other environments where this problem is not occurring.   I think it is more likely that the dll when loaded is occasionally locking the MSVCR71.dll when other processes also need it.    
0
 
sarabandeCommented:
the msvcr71.dll is an extension dll to vc runtime. it contains newer versions of (old) runtime functions for example a strcpy_s as secure alternative to strcpy. dlls are not locked at windows nor do runtime libraries like the msvcr71.dll do any exclusive parts which could dead-lock. on the contrary, any locks would help from the issue you have, cause a lock means wait what would the operation system give a chance to schedule another process/thread and lower cpu usage by that.

so i would bet that it isn't a function of msvcr71.dll which contains the loop but a function of the msvcr71.dll was called in a loop. the loop could be in an error condition only happening in a specific environment. for example when a log or registry value can't be written because of access rights and the program tries to repeat that operation.

the 'widely used' argument is weak cause deployment in a citrix environment means emulation and limited resources what even developers of a widely used dll might have not tested for all functions. you also should see that msvcr71.dll is a multiple time more used than the other dll.

Sara
0
 
efamilantAuthor Commented:
When I run profile on the machine where this is happening, it is the MSVCR71.dll library that is consuming all the resources.    Does that make sense?
0
 
sarabandeCommented:
as told i think the function of msvcr71.dll was called in an endless loop?

does the program ever recover from that state? or do you need to kill it?

if you can run a profiler you might try with a debugger. it should tell you the name of the function in msvcr71.dll and probably the caller. you normally would find the msvcr71.dll in system32 folder together with a msvcr71.pdb. the latter is a debug database and and should help the debugger to locate symbols.

Sara

0
 
sarabandeCommented:
you also could run depends.exe on the third-party dll. it also should tell from where the msvcr71.dll was called (probably from many spots where only one is the critical one).

Sara

0
 
efamilantAuthor Commented:
I ran a profiler on the process causing the problem and it seems to be a swing problem related to an object that is closing (in this case a JOptionPane).    I suspect, but can't confirm, that the problem is probably caused by some object not being created on the Java EDT causing a lock condition related to the MSVCR71.dll

0
 
sarabandeCommented:
again, a wrong lock condition wouldn't make a cpu running at 100%. it would make your program hang.

it is definitive a loop which causes the behavior. either in msvcr71 itself or calling into msvcr71 if your profiler is right.

Sara
0
 
efamilantAuthor Commented:
I solved my bug today.   It was caused by a JDialog being disposed twice.   Why this should result in the CPU spiking, I don't know but removing the second dispose fixed the problem.  
0
 
sarabandeCommented:
good job. such bugs are difficult to solve as they may have worked without problems in other environments.

the citrix needs to emulate resource sharing what may have lead to the problem. if for example they have only one message queue for a dialog id, a multiple running dialog could produce more messages than the dialogs could process because of errors.

Sara
0
 
efamilantAuthor Commented:
This was the right answer.    Although it does not explain why.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 7
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now