shrivastavaa's Posts

I can reproduce it easily with 4.7.0. I will verify it one more time with latest build. If its some small issue(as time permits), I'll try to solve it on the fly. else will log a bug on this. In case you want you may log a ticket with our support after that. I'll update here once done.

>>I've downloaded VM Workstation & ThinApp and was wondering if that's sufficient to run the ThinApp application in? Yes that should be fine. >>For some reason, my PC is a few years old ThinApp as such does not need a very powerfull machine for its own, it all depends upon the application you are capturing. Workstation on the other hand, needs a machine with good RAM to start with. (I ran workstation on a 3 year old C2D machine with 8 GB RAM and it runs fine). >>Can anyone point me in the right direction to get started with Thinapp and packaging applications? Office is a complex appication to start with. I suggest you take a basic free app (like notepad++), package it and get the experience. Than move to office. (should not take much time though). Check this for office http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022287 >> Also does ThinApp run inside any particular O/S? It needs windows 2K+. (google for its manual, that has all these basic answers) Good Luck

I checked the logs finally, From what I observed, the application is loading a DLL imageres.dll, which is loaded successfully as per the logs. Right next to it, is a LoadImage call which is failing, consistently. 467860 0404 03b8 COMCTL32.dll:749e360b<-kernel32.dll:774bb6bf       LoadLibraryExW+ ->*=*A620001h->struct {int unused=300905Ah} (LPCWSTR lpLibFileName=*749E36D4h->L"imageres.dll", HANDLE hFile=0h, DWORD dwFlags=2h) 467865 0404 03b8 COMCTL32.dll:749546a5->USER32.dll  :77132323       LoadImageW+ 467866 0404 03b8 USER32.dll  :771329f8->kernel32.dll:774c29f4         GetModuleFileNameW+ (HMODULE hModule=a620001h, struct {PWSTR lpFilename=*12D0B0h->L"", DWORD nSize=104h) 467867 0000 03b8                                                      GetModuleFileNameW a620001 -> 0 () 467868 0404 03b8 USER32.dll  :771329f8<-kernel32.dll:774c29f4         *** GetModuleFileNameW+ ->unsigned long=0h (HMODULE hModule=a620001h, struct {PWSTR lpFilename=*12D0B0h->L"", DWORD nSize=104h) *** GetLastError 467941 0404 03b8 COMCTL32.dll:749546a5<-USER32.dll  :77132323       *** LoadImageW+  *** GetLastError() returns 126=0x7e [0]: The specified module could not be found. GetModuleFileNameW is failing for A620001h, though the lib is already loaded. Can you please provide me the DLL. I will try to repro it with a test application, if not you need to open a ticket with us. P.S.: Sorry for delayed response.

Now that you know when it works and when it does not. If you are curious and want to know what really failed, you may grab logs of both the cases and compare them. Else you anyways have the workaround.

So these are available natively? I I mean not inside the package but in the system registry? If so, you may want to check what file it is pointing to and if that file exist inside the virtual package, etc. Log monitor logs should put some light on it. You tried looking into them?

You said you looked at the logs in XP, did you search for the said message, did you check for failure around stdole? What does the potential error section says? What happens when the application is installed on system(not thinapped), and you launch it using virtual cmd?

This in general comes from the resource, with in(or out of) the exe. Now thinapp has very little to do here (we do hook a couple of resource related APIs though). What does the log say? Do you mind uploading the log file here?

Welcome to the world of App Compat , these problem will exist. Considering 1000s of applications, from different devs, using various different API/Methods to code. Several hacks in place. Evolving security in OS (integrity mode, UAC) and many more, ThinApp redirects files, registry, and a few more thing and it does that fine. But applications are not limited to just these, they go ahead and uses several other mechanism, when we get a bug on that; we try to fix that, than a new application... App compat is never ending. And than there are certain portion of OS APIs which are non-documented, and keep on changing; and we adjust our code with that as well. The question about why should you use it, should be answer by you. You said application has bugs, OS has bugs; but you do use them. Why? Perhaps even after those bugs they help you reduce your work load, or may be optimize some work, or what ever the reason is. So if App Virt with all its bugs helps you in solving something; use it; else why would you? I can see it may not be a perfect answer for you, but than App Virt is not perfect either. Not yet at least.

Log monitor can easily help you here. You can check the log for missing DLL. You should understand that the exe might be coming with dependent dlls, but those dlls can have further dependency which thinApp is not able to satisfy. There could be n reasons for that. ANd to naroow it down, you'll need to read the log.

Interesting, I am assumming that there is no such crash when you run this application normally (no thinapp involved). If so than the crash (which seems to be a null pointer dereference) might be an issue with us but I can not say it for sure unless I get my hands on the application. Can you share your application; you can raise a support ticket to solve it as well. meanwhile generate the logs from log monitor and upload here.

>> If I virtualize the SWING app,  does the RMI queries still go from the client to the app server (over WAN) or from the app server to the ThinAPP server (over LAN) ? Yes it still goes from client to the app server so no you'll not see any improvement with ThinApp.(It was never the purpose as well)

>>c:\app_path\app.exe->file.dll Is this your dll or third party (from MS, SUN etc). Enable virtual cmd, and try to go to the path mentioned and see if you could locate the said dll their. (What happens if you include this path in PATH variable from virtual CMD) Generate logs using log monitor for app.exe and upload here. (you have to share the exact dll name though for me to dig domething)

Its a known issue since some time and been a pain with couple of application. When running in Vista+, OS with UAC on. Some application like IE, Adobe etc use a thing known as Integrity level while creating the process (when protected mode is on). This does not work with ThinApp yet;  we are working on it and this should be fix soon.