Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Registration of web app failing on a few machines
Options
Previous Topic Next Topic
FSBarker
#1 Posted : Thursday, December 15, 2011 2:31:40 PM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Unfortunately I can't get the exact steps to reproduce, because it is actually a number of machines that I don't have access to and the clients are not mine directly.

At first I thought it was a permissions issue but in looking at the appregtrace.txt it looks like it may be a firewall issue, but I am not installing the app for internet use, but just on the machine it is installed in. I have attached the txt file in the zip, and hope you can tell me how to fix the issue, because I am afraid I will be losing them shortly if not.

It seems to be occuring mostly on windows 7 32 bit, but that may be because that is the most it is being installed on. I have narrowed it down to the Custom action in the set that registered the application, and here is an example of it:

"C:\Program Files\UltiDev\Web Server\UWS.RegApp.exe" /r /host=PrivateLocalSystem /force32=true "/AppLocation=C:\Program Files\Carrier Parts\PLUS T-T\webdir" /AppID={218908BE-407A-41E8-816B-C8005AA5047F} /AppDefaultDoc=default.aspx

When I tried to register without the /host=PrivateLocalSystem I seem to get a run time error.

Thanks for any help,

FSBarker
File Attachment(s):
AppRegTrace.zip (4kb) downloaded 119 time(s).
Back to top
WWW
Ultidev Team
#2 Posted : Thursday, December 15, 2011 3:01:40 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi there!

Could you please also attach "UWS.Installer.log.txt" - it will contain more information?

It is most likely that it's a permission problem. We see "User security context: NT AUTHORITY\SYSTEM (XXXXX\SYSTEM), Elevated: False", even though AppReg.exe demands elevated privileges. So we'd like to see what OS the system is under.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
FSBarker
#3 Posted : Thursday, December 15, 2011 3:16:01 PM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
I am having them forward me that file, as well as the other file mentioned in your posting on submitting bugs.

In the meantime a quick question: What is weird is that we have specifide that they need to install using the Administrator account, which I thought would have elevated permissions. Is there other steps they need to take to make sure it the privelages are elevated enough?

Sorry, not a systems guy, and although I have used Cassini with my app for the last few years, never had these issues before. Plus for the life of me can't get the installation to fail for myself, so can't repro it.

Thanks again for your quick response, you and your product rocks!

Scott
Back to top
WWW
 |  Edit by user
Ultidev Team
#4 Posted : Thursday, December 15, 2011 4:26:29 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi, Scott.

The situation is pretty strange indeed. Administrator is not always elevated on the Vista/7/2008. By default it's not elevated. But, RegApp.exe demands elevation in its manifest, which should pop up that annoying system elevation prompt, and if users okays it, it should run elevated, and the user cancels it, the program should not run at all. And yet it is running not elevated somehow. We are wondering if target system is XP and we have some flaw in our elevation check logic. We'll know more once we get the log we have asked for. This is the first report of this kind of problem. We'll do our best to figure this one out.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
FSBarker
#5 Posted : Thursday, December 15, 2011 7:08:36 PM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
As far as I have been told they are all 32 bit windows 7 machines. I don't think we have had any problems with xp that i have hear.

We have also told them to install as admin, and answer yes to elevated privilages, but who knows.

This is running in the Custom Action of an MSI setup.

I have included the two other log files here. Thanks again.

Scott
File Attachment(s):
UWS.Installer.log.zip (4kb) downloaded 117 time(s).
Back to top
WWW
1 user thanked FSBarker for this useful post.
Ultidev Team on 12/21/2011(UTC)
Ultidev Team
#6 Posted : Friday, December 16, 2011 12:46:31 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Scott,

This is a total mystery. Logs show other actions that require elevation, like GAC changes, Windows firewall configuration, etc., working just fine. It acts as if only UWS.RegApp.exe is run without elevation, and it fails to register not only your application, but also ours.

Would it be possible to ask your user to download our latest build (build 14), which is not likely to change the outcome, and more important, to ask them to export Windows Event Log as EVTX file and send us for analysis?

May be this "InvalidOperationException This access control list is not in canonical form" exception is something not related to elevation. Event log could help.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
FSBarker
#7 Posted : Friday, December 16, 2011 1:10:19 AM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Creating the MSI using VS 2008 shouldn't cause this kind of issue would it? I could try it in VS 2010 but just didn't want to introduce any other new variables.

I had thought that this log was using build 14. Is this not the case? If not I will rebuild and have it included.

I will also see if I can get the other information you need.

Scott
Back to top
WWW
FSBarker
#8 Posted : Friday, December 16, 2011 3:08:20 AM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
OK, I am probably going to do a share session with the client, and install a new version of the product that has version 14 UWS in it.

I have created the new version, and installed it onto a Windows 7 32 bit machine with no problems.

I have attached the log files, including windows log events, for the successfull install thinking it may give you some further insite.

I will also try and get the windows event logs from him computer as well if possible.

Thanks.

Scott
File Attachment(s):
PLUSInstallWithUWS Good.zip (11kb) downloaded 117 time(s).
Back to top
WWW
Ultidev Team
#9 Posted : Friday, December 16, 2011 1:05:06 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Thanks you, Scott.

We also have tested UWS with windows 7 32 and 64 bit and never saw this problem. We have never had anyone else reporting this problem before. It would be great if we could reproduce this problem.

Best regards.
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
FSBarker
#10 Posted : Tuesday, December 20, 2011 3:45:51 PM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
OK, here is the event logs, along with the other logs requested. I also included the latest version of the UWS I believe.

Hopefully you can look at this and see what they or I am doing wrong, or if there is an issue somewhere else. Pretty desparate at this point. :)

Scott
File Attachment(s):
plus issue.zip (21kb) downloaded 123 time(s).
Back to top
WWW
Ultidev Team
#11 Posted : Tuesday, December 20, 2011 4:42:21 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hello, Scott.

Thank you for comprehensive log submission. We found a couple of things worth mentioning:
- First one, although it probably won't make the problem go away, is that UWS installed today was still build 11, not the latest one (14) as your have stated.
- Counter to what we thought, registration of UWS internal redirector application is successful, while your application installation is not, despite both being installed from LocalSystem account which is shown as non-elevated. Would you be able to point the browser to http://<machinename>:7756/ and see whether you can get to UWS internal redirector page?

We have tested your command line on one of our test systems, with changing only physical location and default doc name, and it worked fine. We'll the test more with 32-bit windows 7 again and will keep you posted as to how it went. Still, it looks like something is odd about this particular system, and we'd like to figure what that is. Can you think of anything that is stating out about this box? We assume you have successfully tested the same installation against similar configurations with success?

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
FSBarker
#12 Posted : Tuesday, December 20, 2011 10:11:53 PM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Thanks for looking at this so quickly.

The weird thing is that they have been distributing the system on a number of machines in various companies, with various networks, and computers. We have had about 10 come up with this same error I believe, seemingly all Windows 32 bit machines.

Trying to find out more is tough since they are not machines I have ready access to.

Also, it should have used 14 since that is what the test machine comes up with correctly. I will see if I can try and get him to see the redirect you ask for, and if he can look at the version number.

Question: Firewalls should not be an issue since we are just installing locally and using it as such, correct?

Question: Would installing the app in Program Files be an issue on some machine? It has never been in the past but I am just trying to throw different ideas out.




Scott
Back to top
WWW
Ultidev Team
#13 Posted : Wednesday, December 21, 2011 9:31:06 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hello, Scott.

We think it's neither firewall nor "Program Files" issue. UltiDev's own Redirector application is installed in "C:\Program Files (x86)\UltiDev\Web Server\Redirector" and is registered successfully, according to your logs. The only significant difference between your application registration and ours is that yours is registered with a "Local System" host process and ours is with "Network Service". That, combined with something unusual about the target system, makes it fail. We are working on more testing in different configurations, still trying to reproduce the problem.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
 |  Edit by user
Ultidev Team
#14 Posted : Wednesday, December 21, 2011 11:12:35 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
UPDATE:
Scott, we found that your application registration and ours are different after all. Your application probably has App_Data folder that UWS tries to grant its host process "Modify" access rights to it. UWS Redirector does not have App_Data folder. We are still not sure what if anything we can do to make this problem go away in this version because the problem may be caused by current access rights on the hierarchy down from the installation folder of the system where installation breaks. We will change logic of modifying App_Data access rights in the next release so that it will let your application register properly (since your host process runs under Local System and thus won't need granting rights to App_Data), but if you ever decide to switch your host from Local System to Network Service, the issue may reappear.

Please let us know if this information was helpful.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
FSBarker
#15 Posted : Wednesday, December 21, 2011 11:29:43 AM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
So if I modified the registration to use the Network Service would the issue go away? Doesn't sound like it. I do in fact have a App_data folder in it, as do alot of ASP.NET applications run on local machines I would think.

I had registered it as such originally (Network Service, the default right?) and had issues running the application because of it. After reading in the forums about something similar I changed it to use Local System and it took care of the issue.

In this case I don't actually need modifcation rights to the App_Data folder, just Read access.

Although this doesn't give me an immediate solution, which I kind of need, it at least points me in a direction.

Update: I could install the web application in the ProgramData folder rather than in the Program Files folder, if that would make it so access wouldn't be a problem? I need all users to have access to the application and data. Also need it to work on XP.

Thanks again, and if you think of anything else, all help would be appreciated.

Scott
Back to top
WWW
 |  Edit by user
Ultidev Team
#16 Posted : Wednesday, December 21, 2011 12:46:27 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Scott,

If all you need is read access to files in App_Folder, we think the work around would be to put the file(s) in another folder, and remove App_data folder altogether. UWS registration attempts to change permissions only on App_Data folder. If your app does not have this folder, you should not have the problem.

Moving the app to another folder may or may not help, so don't need to bother. Our suggestion above should resolve the issue, even for Local System host. Please try it and ask the user who's having trouble to test it.

Please let us know if this information was helpful.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
 |  Edit by user
FSBarker
#17 Posted : Wednesday, December 21, 2011 1:29:53 PM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)

I will create a new folder under the app, and move the database into it. And then remove APP_DATA and see if that works.

The only other thing that makes me nervous is my app creates an xml file under it in one of the sub folders, but it should still be created fine, just as it did under the old version of the web server, right?

I don't have many trips to the well of having the people who have the issues re-installing the app alot, since it is a big application. I have one of the willing to work with me, but he is pretty busy also.

Thanks again, and wish me luck.

Scott
Back to top
WWW
Ultidev Team
#18 Posted : Wednesday, December 21, 2011 1:53:11 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi, Scott.

If you are running under Local System, you can create a folder or a file just about anywhere on the system, so you should be alright with putting an xml file in a sub-folder.

We are reasonably sure that the work-around should work, because UWS Redirector app seems to get registered fine. And in the next release we'll make the failure to ACL the App_Data folder non-catastrophic: we'll log the warning and let the small percentage of users affected by the problem to deal with it by ACLing the folder manually, through Windows Explorer.

We are sorry for the inconvenience: we have not seen this problem before, and with hundreds of configurations out there things do go wrong. Also, thank you for collecting all the logs - they made possible to narrow down the cause to a single line of code.

Please let us know whether the suggested work-around has fixed the problem. Good luck!

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
 |  Edit by user
FSBarker
#19 Posted : Wednesday, December 21, 2011 1:57:19 PM(UTC)
Groups: Member
Joined: 10/13/2011(UTC)
Posts: 10
Location: Seattle

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Sounds good. Thanks again for the all the quick replies. We have enjoyed working with the product for years, and it is great when we actually have a major issue in our eyes, you nailed the cause down for us quickly. (Hopefully this is it.:))

Will let you know.

Scott
Back to top
WWW
Ultidev Team
#20 Posted : Wednesday, December 21, 2011 3:14:55 PM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Thank you! Hopefully we don't jinx it by calling the issue almost certainly resolved until it's verified.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
 |  Edit by user
Rss Feed  Atom Feed
Users browsing this topic
Guest (2)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You can vote in polls in this forum.

Powered by YAF 1.9.5.5 | YAF © 2003-2011, Yet Another Forum.NET