I sequenced an application with AppV.

I deployed it to several people and it was working fine for everyone.

One person just started getting this error: globalroutines.initresourceManager / Bad file name or number

It had been working fine for him but one day this error started after the application shows loaded 100% but before it actually launches. Others are still running the application just fine.

I Un-loaded/ Cleared / Deleted ALL of his applications, then Refreshed them, but still get the same error.

I am not sure if this error is being reported from AppV or from the application that was sequenced. I am checking with that application's support group, but wanted to check here in case that error is recognized.

Are there logs that might help determine if this is AppV or the application itself that is reporting this error?

As always, any input you can offer is greatly appreciated.

-Joel



0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
hi Joel,

If it's only happening for one user then it's something outside of the package itself; .PKG file/local dependency/network resource or some other external factor.

My first move would be to delete his .PKG files for the app and see if that resolves the issue. (this isn't cleared if you're just deleting the app)

Failing that I'd check the external factors (can this user launch the app on another 'working' machine etc) and use Procmon to see if you can get some clues. I don't think the app-v logs are going to be the best place to look for this as it looks like an internal app specific issue.

Cheers,
Danny
Answered 10/25/2010 by: DannyC
Orange Belt

Please log in to comment
0
Thanks for the quick reply Danny.

Regarding the .PKG files, he doesn't actually have any for this application, it appears that the application is failing before the .PKG files are created. I tested on a working system by deleting the application's associated folder in the AppF5 Storage folder. It looks like the files are created as .TMP files until some point when the application is successfully launched and then they become .PKG files. Since his system never successfully launches the application, they remain as .TMP files.

I deleted the folder containing the .TMP files but he is still getting the same error and the folder and .TMP files are recreated.

I logged into another computer at his location using his credentials and successfully launched the application that is failing on his PC so it would appear to be an issue only on his PC.

I haven't used Procmon before, but I will find it and give it a try comparing the results form his PC to the test PC and hopefully something will jump out to help resolve this.

I will report my progress, thanks again!
Answered 10/25/2010 by: snj2000
Orange Belt

Please log in to comment
0
I used Procmon to monitor the application launch on the failing and working system and compared the two.

The first thing that jumps out at me is:

WriteFile
Q:\AspMGpHF.001\Aspect Software\Unified IP Client\Logs\epro\DBIClient\Logs\EnterpriseMonitor_DBIClient-10.10.25-16.45.48.074.log
DISK FULL

I only see that from the Procmon log of the failing system.

Is there a way to cleanup the Q disk or review what is on it?

Thanks

-Joel
Answered 10/25/2010 by: snj2000
Orange Belt

Please log in to comment
0
I removed and then re-installed the App-V client on his PC and now he is able to launch all of his applications.

Not really sure what caused the issue other than the Procmon entry that indicated the Q drive was full.

Not sure how to monitor, clear or expand the Q drive.
Answered 10/26/2010 by: snj2000
Orange Belt

Please log in to comment
0
Hi snj2000,

If you stumble upon this again, there's no need to reinstall the App-V Client. A full Q drive is probably the result of the App-V cache being full. The cache can be resetted by either the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\AppFS\State


Or by using the following command line:

sftmime.exe remove obj:app /global /complete



And if this starts to occur more often, you might want to think about increasing cache size of course....
Answered 10/28/2010 by: Rheuvel
Brown Belt

Please log in to comment
0
Well as luck would have it, that same client is reporting DISK FULL again.

I issued:
sftmime.exe remove obj:app /global /complete

I can see that it cleared his cache by looking at the File System Tab, but he is still getting Disk Full when he launches his application.

I have also tried the registry change.

Any idea what I might be missing?

Thanks



Answered 11/01/2010 by: snj2000
Orange Belt

Please log in to comment
0
That sounds like a problem with the user cache then if other clients don't have this problem at all. If for some reason an application is making major changes (I have once encountered this) it could be that those changes are done 'inside' the bubble for whatever reason.

My approach to this would be:

First find out which application is causing this exactly and wheter it is the global app-v cache or the user cache.

Download the ACDC tool to find out which application is flooding the cache. It's a single exe. Run in on the client that's having problems. In the cache or diagnostic tabs it displays the exact application cache size, but also the user cache size. Find which app is flooding your system.

If it is the global cache for your client, it's just too small. You'll have to increase it in that case (ACDC will let you do that as well if run as admin).

However, if it is the user cache, you'll have a bigger challenge. The user cache has a max size that can't be changed, so you could delete the user cache for that app and pray, but it's likely that the cache will be filled again on the first run. You will want to find out what is causing the cache to flood.

To do that, download the trial version of AVE Prof. (bottom of page). AVE allows you to open and browse inside the user cache of any app-v package (it's a .pkg file, ACDC wil point you to the right location). Once inside the .pkg, find the file that's flooding the cache and next, find out 'why' that file is in your cache and how you can get (and keep) it out in the future.


Good luck!
Answered 11/02/2010 by: Rheuvel
Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity