LUA Buglight updated information

Aaron Margosis' WebLog : LUA Buglight public [pre]-release

Aaron Margosis' WebLog : LUA Buglight public [pre]-release — Fri, 16 Feb 2007 05:21:39 GMT

PingBack from http://blogs.msdn.com/aaron_margosis/archive/2006/08/07/LuaBuglight.aspx

re: LUA Buglight updated information

JohnCKirk — Fri, 16 Feb 2007 15:48:49 GMT

Hi Aaron - thanks for checking into that for me.

One other issue I've noticed recently is that you have to enter a password for both accounts (admin and non-admin). In other words, even if those accounts don't have passwords defined, the LUA Buglight tool says "Credentials incomplete", and won't run.

There's a fairly simple workaround (i.e. assign passwords!), but is that essential from a technical point of view? (For instance, we have guest PCs at my company, where the local admin account has a password but the limited user accounts don't.)

JohnCKirk: Technically, kind of yes, except that (by default) local accounts without passwords cannot be used for anything except interactive logon. I'd have to check, but I don't think the accounts could be usable in this scenario without turning off the security policy (which I don't recommend doing).

-- Aaron

re: LUA Buglight updated information

Josh — Thu, 22 Feb 2007 16:25:38 GMT

this might work as a workaround for your drive issues.

http://www.windowsconnected.com/blogs/joshs_blog/archive/2007/02/20/windows-vista-tip-enabledlinkedconnections.aspx

Josh, thanks. Two things, though: 1. That applies only to Vista; and 2. LUA Buglight is designed not to require nor make permanent settings changes to the target system.

-- Aaron

re: LUA Buglight updated information

JohnCKirk — Mon, 12 Mar 2007 15:52:45 GMT

As a quick follow-up on the Cisco Network Assistant issue, my previous problems with LUA were my own fault - I'd forgotten to change the startup folder to be the main folder rather than the "prelaunch" subfolder. Sorry about that.

Meanwhile, Cisco have released a new version of the tool (v5.1) which is something of a mixed blessing. On the one hand, if you run it as a limited user then it now gives you an error message (rather than going into an infinite loop). This message says:

-- Begin quoted message --

Read/write access problems:

Access is denied

=======================================

Note: Read/write access is required for user home directory and installation directory:

C:\Documents and Settings\jkirk

C:\Program Files\Cisco Systems\Cisco Network Assistant

=======================================

-- End quoted message --

I tried your fix for the LOCK file, but unfortunately it's also doing the same thing with a temporary file, and this seems to be a randomly generated name (i.e. different each time). The first time I ran the program, the file was "tempFile63013796062581692271173702585959220391179812494596", and the second time it was "tempFile47197921121043939101173703104252836960705251599367". This looks as if Cisco are deliberately trying to stop this kind of workaround, and make sure that you do have full permission to that folder, although I can't see why.

Anyway, I agree with you that assigning folder-level permissions isn't ideal, but in this case I think it's the only solution.

You're right both that changing the folder permissions is unfortunate and that given the random filename, it may be the only way to get it to work. If you're in contact with Cisco's support organization, perhaps you could point them to this blog post.

-- Aaron

re: LUA Buglight updated information

Jared — Fri, 07 Dec 2007 03:23:11 GMT

Aaron,

Want to thank you for your amazing LUA Buglight tool. Saved us big time today!

re: LUA Buglight updated information

Craig — Wed, 27 Feb 2008 20:39:08 GMT

Hi Aaron,

Is it possible to use LUA Buglight on a COM+ application? I have tried setting the app to a service and running dllhost manually inside the program, but it terminates immediately. Any other thoughts on LUA with COM+ applications would be welcome.

[Aaron Margosis] Right now LUA Buglight is designed to be used only with interactive desktop applications. Can you move the code into another context? E.g., create a desktop app that invokes it as an in-proc COM component -- or as a DCOM local server component in the same security context as the interactive user?

re: LUA Buglight updated information

Alain Beaulieu — Tue, 08 Apr 2008 08:37:05 GMT

08/04/2008

J`ai besoin d`information sur ce produit car j`ai exécuté plusieurs téléchargement ex: Platform SDK for windows server 2008 précédemment 2003 et Débuging tool ainsi que service pack 1 32 bits.

C`est pourquoi j`aurais besoin de ces informations le plus rapidement possible une semaine tout au plus pour que je puisse me remettre a continuer a amiliorer mon ordinateur.

Je vous souhaite bonne nuit a Quebec il est 01h37.

Mercie.

Alain Beaulieu

[Aaron Margosis] My French isn't that good anymore and Altavista translations doesn't help much here, but I get the impression that your comment has nothing to do with the subject of this blog post. Please post again (in English, please) if I am mistaken.

re: LUA Buglight updated information

Sasha Goldshtein — Sat, 12 Apr 2008 12:09:13 GMT

First of all, thanks for a cool tool! How would you contrast it to existing tools, such as Application Verifier's LUA emulation, or Application Compatibility Toolkit?

Another thing I encountered is that the tool fails to work for 64-bit processes. The error seems to come from the Detours DLL, which is probably a 32-bit image so it can't be loaded into the target 64-bit process...

exit code 0xc0000022

Tony — Thu, 18 Sep 2008 17:52:02 GMT

Aaron,

We were using this tool on an application and received the following exit code: 0xc0000022. The Viewer doesnt show any files/keys to be modified when you launch the viewer. I can run the application as an administrator but not as a non-admin.

Some google'ing on the exit code suggested the msvcp71.dll may not be registered. Ideas?