AppV application error: globalroutines.initresourceManager
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
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
Answers (7)
Please log in to answer
Posted by:
DannyC
14 years ago
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
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
Posted by:
snj2000
14 years ago
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!
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!
Posted by:
snj2000
14 years ago
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
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
Posted by:
snj2000
14 years ago
Posted by:
Rheuvel
14 years ago
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....
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....
Posted by:
snj2000
14 years ago
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
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
Posted by:
Rheuvel
14 years ago
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!
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!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.