Peculiar Behavior in IEExec
-
Hopefully there are enough "ieexec" gurus out there to help me with this problem. I've agressively searched for an answer to this new behavior but it is either too new or somewhat unknown. For .Net Framework 1.0 SP2, "ieexec" will NTD launch an application with a link like this... http://server.com/app.exe?foo=bar ...with these parameters... arg 0: http://server.com/app.exe?foo=bar arg 1: 3 (this indicates what kind of evidence to generate to the app domain) arg 2: 3 (if arg 1 is set, this is what type zone to setup the evidence) arg 3: 86474707A307074636E20727F607C616E6E65627E2E6564730000000 (this is a site id) For .Net Framework 1.0 SP3, "ieexec" will fail where Fusion claims the binary downloaded can't be opened and inspected. It throws an
InvalidProgramExceptionwhen it tries to open the manifest which causes it to throw aFileNotFoundException. Inspecting the binary by hand it appears to be the exact same binary that is valid and well formed and should be executible. Scratching my head I removed the "foo=bar" parameters from the Url and retry it but then I observe "ieexec doing this instead: arg 0: http://server.com/app.exe#1A6D780865D8184107287EFF1A3DF156B06330E4 arg 1: 3 (this indicates what kind of evidence to generate to the app domain) arg 2: 3 (if arg 1 is set, this is what type zone to setup the evidence) arg 3: 86474707A307074636E20727F607C616E6E65627E2E6564730000000 (this is a site id) This kind of leads me to two questions: - What in the world is the extra "#" data on the url? Is it actually useful for anything? - Can the extra "#" data interfere with "ieexec" to the point where it can no longer parse/ignore parameters? I'm kind of stuck at this point. In general NTD isn't a widely known or documented topic. Does anyone out there have any insight into what is going on between SP2 and SP3? -
Hopefully there are enough "ieexec" gurus out there to help me with this problem. I've agressively searched for an answer to this new behavior but it is either too new or somewhat unknown. For .Net Framework 1.0 SP2, "ieexec" will NTD launch an application with a link like this... http://server.com/app.exe?foo=bar ...with these parameters... arg 0: http://server.com/app.exe?foo=bar arg 1: 3 (this indicates what kind of evidence to generate to the app domain) arg 2: 3 (if arg 1 is set, this is what type zone to setup the evidence) arg 3: 86474707A307074636E20727F607C616E6E65627E2E6564730000000 (this is a site id) For .Net Framework 1.0 SP3, "ieexec" will fail where Fusion claims the binary downloaded can't be opened and inspected. It throws an
InvalidProgramExceptionwhen it tries to open the manifest which causes it to throw aFileNotFoundException. Inspecting the binary by hand it appears to be the exact same binary that is valid and well formed and should be executible. Scratching my head I removed the "foo=bar" parameters from the Url and retry it but then I observe "ieexec doing this instead: arg 0: http://server.com/app.exe#1A6D780865D8184107287EFF1A3DF156B06330E4 arg 1: 3 (this indicates what kind of evidence to generate to the app domain) arg 2: 3 (if arg 1 is set, this is what type zone to setup the evidence) arg 3: 86474707A307074636E20727F607C616E6E65627E2E6564730000000 (this is a site id) This kind of leads me to two questions: - What in the world is the extra "#" data on the url? Is it actually useful for anything? - Can the extra "#" data interfere with "ieexec" to the point where it can no longer parse/ignore parameters? I'm kind of stuck at this point. In general NTD isn't a widely known or documented topic. Does anyone out there have any insight into what is going on between SP2 and SP3?Tom Larsen wrote: In general NTD isn't a widely known or documented topic. We (Proplanner) were actually the first to use it in a commercial application that I could find. I designed Proplanner that way before the documentation was even finalized on NTD. There are a few others that I communicated with on occassion about problems that did get pushed to Microsoft eventually (a couple years ago). So, when you removed all key=value pairs (leaving just the bare application name as http://server.com/app.exe) IEExec appended "#..."? Have you disassembled IEExec.exe (and related assemblies) to find why this might be happening? This is actually how I and another guy discovered that we could get buy passing query-string-like parameters to a NTD app link. IEExec.exe and related assemblies were updated by SP3 (which is easy to determine by opening the .NET 1.0 RTM in Orca then extracting SP3's MSP and click View Patch in Orca and appling the patch visually - quick slick and I used it many times at Proplanner and use it all the time here now), so the problem is most likely related to SP3 (which you already knew; just wittling down problem areas). Taking a quick look it does look like IEExec.exe will parse and decode anything after the hash (#), so be sure that no % signs exist or they'll be decoded (shouldn't, but just double check). To provide any further help, though, you'll need to answer my question whether just executing the application - with absolutely nothing after .exe still works. Also, have you checked to make sure that your IHttpHandler for ".exe" isn't causing the problem (the one that passes the .config file since the "command-line args" screw up the URL)? This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]
-
Tom Larsen wrote: In general NTD isn't a widely known or documented topic. We (Proplanner) were actually the first to use it in a commercial application that I could find. I designed Proplanner that way before the documentation was even finalized on NTD. There are a few others that I communicated with on occassion about problems that did get pushed to Microsoft eventually (a couple years ago). So, when you removed all key=value pairs (leaving just the bare application name as http://server.com/app.exe) IEExec appended "#..."? Have you disassembled IEExec.exe (and related assemblies) to find why this might be happening? This is actually how I and another guy discovered that we could get buy passing query-string-like parameters to a NTD app link. IEExec.exe and related assemblies were updated by SP3 (which is easy to determine by opening the .NET 1.0 RTM in Orca then extracting SP3's MSP and click View Patch in Orca and appling the patch visually - quick slick and I used it many times at Proplanner and use it all the time here now), so the problem is most likely related to SP3 (which you already knew; just wittling down problem areas). Taking a quick look it does look like IEExec.exe will parse and decode anything after the hash (#), so be sure that no % signs exist or they'll be decoded (shouldn't, but just double check). To provide any further help, though, you'll need to answer my question whether just executing the application - with absolutely nothing after .exe still works. Also, have you checked to make sure that your IHttpHandler for ".exe" isn't causing the problem (the one that passes the .config file since the "command-line args" screw up the URL)? This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]
The application will launch without parameters (ie. http://server.com/app.exe) but without the parameters it will not function correctly. The "#blahblahblah" is generated by something else. Is that extra data appended by IE when it launches "ieexec"? I'm not exactly sure. I still haven't located inside "ieexec" what it is doing with that "#blahblahblah" data. The
IHttpHandlerappears to be functioning correctly (passing urls returns the right stuff, eg http://sever.com/app.exe gives me the binary vs http://server.com/app.exe.config gives me the config file and all combations there of). -
The application will launch without parameters (ie. http://server.com/app.exe) but without the parameters it will not function correctly. The "#blahblahblah" is generated by something else. Is that extra data appended by IE when it launches "ieexec"? I'm not exactly sure. I still haven't located inside "ieexec" what it is doing with that "#blahblahblah" data. The
IHttpHandlerappears to be functioning correctly (passing urls returns the right stuff, eg http://sever.com/app.exe gives me the binary vs http://server.com/app.exe.config gives me the config file and all combations there of).I don't remember - that NTD executable is not being run over HTTPS, right? See http://support.microsoft.com/default.aspx?scid=kb;en-us;312546[^]. Same symptoms, it seems. One other idea occured to me. Grab the SP2 assemblies including and related to IEExec.exe and disassemble them with ildasm.exe (on the command line, use the /out:filename.il along with the assembly path to disassemble to a file). Do the same with the SP3 assemblies and diff the similar .il files. Looking in the assemblies (using either ildasm.exe or .NET Reflector) I don't see anything off hand about why this would fail. Most likely it's a client side issue, from the sounds of it, in which case 9/10 fingers point to IEExec.exe like you have diagnosed. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles]