piping and teeing
-
I'm not a Vista user, so please bear with me if this is common knowledge. I have a batch script that pipes it's output to tee.exe, when outputs to a log file as well as the console window. It works fine on any O/S except, of course, Vista. What happens is a dialog box pops up saying "tee.exe has stopped working" and "Windows is checking for a solution to the problem..." with a progress bar. After a while the dialog changes to "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.", and displays Debug and Close program buttons. Clicking the Debug button brings up the following JIT window message "An unhandled win32 exception occurred in tee.exe [4872]". My guess is that Vista doesn't want processes to pipe data back and forth, for understandable security reasons. Is this indeed what's going on, and is there any way to get this to run on Vista? Thanks in advance for your advice.
QRZ? de WAØTTN
-
I'm not a Vista user, so please bear with me if this is common knowledge. I have a batch script that pipes it's output to tee.exe, when outputs to a log file as well as the console window. It works fine on any O/S except, of course, Vista. What happens is a dialog box pops up saying "tee.exe has stopped working" and "Windows is checking for a solution to the problem..." with a progress bar. After a while the dialog changes to "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.", and displays Debug and Close program buttons. Clicking the Debug button brings up the following JIT window message "An unhandled win32 exception occurred in tee.exe [4872]". My guess is that Vista doesn't want processes to pipe data back and forth, for understandable security reasons. Is this indeed what's going on, and is there any way to get this to run on Vista? Thanks in advance for your advice.
QRZ? de WAØTTN
Do you have the same problem if the script is run with elevated privileges? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Do you have the same problem if the script is run with elevated privileges? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Thanks for the response Mark. Do you mean running as an admin on the machine? If so, yes. This is not me, by the way, I'm just trying to get this build process running for someone on a Vista system. So I can't tell you too much more about it myself.
QRZ? de WAØTTN
-
Thanks for the response Mark. Do you mean running as an admin on the machine? If so, yes. This is not me, by the way, I'm just trying to get this build process running for someone on a Vista system. So I can't tell you too much more about it myself.
QRZ? de WAØTTN
NetDave wrote:
Do you mean running as an admin on the machine?
Yes, not just an administrator logged in, but for example, right-clicking the command prompt shortcut and choosing "run as administrator". Beyond that, I know nothing - I've never even heard of the tee utility :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
NetDave wrote:
Do you mean running as an admin on the machine?
Yes, not just an administrator logged in, but for example, right-clicking the command prompt shortcut and choosing "run as administrator". Beyond that, I know nothing - I've never even heard of the tee utility :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
Yes, not just an administrator logged in, but for example, right-clicking the command prompt shortcut and choosing "run as administrator".
Well, here's what's actually happening. We open a command window, and I'm assuming we've got admin priv's within it, and then execute a script (build.cmd). The script then executes another script and pipes the output to the tee utility, which sends the output to both the command window for viewing and a file for logging. So maybe we need to set the second script file to run as administrator? I'll pass this along to the guy (he's at a different facility than me) and see if he can diddle around with the privileges of all the scripts involved - the tee.exe didn't show any "run as" options. Thanks Mark!
QRZ? de WAØTTN
-
Mark Salsbery wrote:
Yes, not just an administrator logged in, but for example, right-clicking the command prompt shortcut and choosing "run as administrator".
Well, here's what's actually happening. We open a command window, and I'm assuming we've got admin priv's within it, and then execute a script (build.cmd). The script then executes another script and pipes the output to the tee utility, which sends the output to both the command window for viewing and a file for logging. So maybe we need to set the second script file to run as administrator? I'll pass this along to the guy (he's at a different facility than me) and see if he can diddle around with the privileges of all the scripts involved - the tee.exe didn't show any "run as" options. Thanks Mark!
QRZ? de WAØTTN
NetDave wrote:
I'm assuming we've got admin priv's within it
That's not a valid assumption unless you explicitly run the command window as an administrator, either by changing the default setting on the shortcut or the right-click method I mentioned before. Processes spawned by the command prompt should run with the same elevated privileges AFAIK. Are you using Windows Power Shell? Again, I know nothing about it, but when I looked around I saw mention of TEE and Vista compatibility. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
NetDave wrote:
I'm assuming we've got admin priv's within it
That's not a valid assumption unless you explicitly run the command window as an administrator, either by changing the default setting on the shortcut or the right-click method I mentioned before. Processes spawned by the command prompt should run with the same elevated privileges AFAIK. Are you using Windows Power Shell? Again, I know nothing about it, but when I looked around I saw mention of TEE and Vista compatibility. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
That's not a valid assumption unless you explicitly run the command window as an administrator, either by changing the default setting on the shortcut or the right-click method I mentioned before.
I don't know for sure how my buddy is starting the command window, but I usually just run cmd.exe. I don't think there are any settings for "run as" for an executable, are there? But I will have him check the script files and see if there are "run as" settings for them. And no, we're not using the power shell. It sounds like a good idea to look into it though. It seemed like overkill for all the scripts I run, but it might be the answer in this case.
QRZ? de WAØTTN
-
Mark Salsbery wrote:
That's not a valid assumption unless you explicitly run the command window as an administrator, either by changing the default setting on the shortcut or the right-click method I mentioned before.
I don't know for sure how my buddy is starting the command window, but I usually just run cmd.exe. I don't think there are any settings for "run as" for an executable, are there? But I will have him check the script files and see if there are "run as" settings for them. And no, we're not using the power shell. It sounds like a good idea to look into it though. It seemed like overkill for all the scripts I run, but it might be the answer in this case.
QRZ? de WAØTTN
NetDave wrote:
I usually just run cmd.exe
That's not enough on Vista. Even if you're an administrator, apps run without elevated privilege unless you specifically run it elevated or the app itself requests it (which cmd.exe does not). runas won't help here, since running as a different administrator still leaves the same problem described above. Stumbled across this just now... Scripting Elevation on Vista[^]
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Mark Salsbery wrote:
That's not a valid assumption unless you explicitly run the command window as an administrator, either by changing the default setting on the shortcut or the right-click method I mentioned before.
I don't know for sure how my buddy is starting the command window, but I usually just run cmd.exe. I don't think there are any settings for "run as" for an executable, are there? But I will have him check the script files and see if there are "run as" settings for them. And no, we're not using the power shell. It sounds like a good idea to look into it though. It seemed like overkill for all the scripts I run, but it might be the answer in this case.
QRZ? de WAØTTN
If you want to run cmd.exe as Administrator you can find it in the System32 (C://Windows/System32) folder then right-click on it and select "Run as Administrator". Unfortunately you can't select the "Run with administrative privileges" flag for cmd.exe in the properties dialog but what I've done is created a shortcut to cmd.exe and put it on the Start menu so I can easily right click on it and run it as Admin whenever I need to without having to wade through the all the cr*p that MS have put in the System32 folder to find it. Regards, --Perspx
"I've got my kids brainwashed: You don't use Google, and you don't use an iPod." - Steve Ballmer
"Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen an angry penguin charging at them in excess of 100mph." - Linus Torvalds -
I'm not a Vista user, so please bear with me if this is common knowledge. I have a batch script that pipes it's output to tee.exe, when outputs to a log file as well as the console window. It works fine on any O/S except, of course, Vista. What happens is a dialog box pops up saying "tee.exe has stopped working" and "Windows is checking for a solution to the problem..." with a progress bar. After a while the dialog changes to "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.", and displays Debug and Close program buttons. Clicking the Debug button brings up the following JIT window message "An unhandled win32 exception occurred in tee.exe [4872]". My guess is that Vista doesn't want processes to pipe data back and forth, for understandable security reasons. Is this indeed what's going on, and is there any way to get this to run on Vista? Thanks in advance for your advice.
QRZ? de WAØTTN
Thanks for all the responses so far. The coworker who is having this problem is going on vacation until the end of October, so this project is on hold until then. When he gets back we'll look into the suggestions and I'll report back on what, if anything, we find. Thanks again for the quick responses :cool:
QRZ? de WAØTTN
-
I'm not a Vista user, so please bear with me if this is common knowledge. I have a batch script that pipes it's output to tee.exe, when outputs to a log file as well as the console window. It works fine on any O/S except, of course, Vista. What happens is a dialog box pops up saying "tee.exe has stopped working" and "Windows is checking for a solution to the problem..." with a progress bar. After a while the dialog changes to "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.", and displays Debug and Close program buttons. Clicking the Debug button brings up the following JIT window message "An unhandled win32 exception occurred in tee.exe [4872]". My guess is that Vista doesn't want processes to pipe data back and forth, for understandable security reasons. Is this indeed what's going on, and is there any way to get this to run on Vista? Thanks in advance for your advice.
QRZ? de WAØTTN
Piping works fine. Sounds like tee.exe has a latent bug that only shows up on Windows Vista.
"Multithreading is just one damn thing after, before, or simultaneous with another." - Andrei Alexandrescu
-
I'm not a Vista user, so please bear with me if this is common knowledge. I have a batch script that pipes it's output to tee.exe, when outputs to a log file as well as the console window. It works fine on any O/S except, of course, Vista. What happens is a dialog box pops up saying "tee.exe has stopped working" and "Windows is checking for a solution to the problem..." with a progress bar. After a while the dialog changes to "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.", and displays Debug and Close program buttons. Clicking the Debug button brings up the following JIT window message "An unhandled win32 exception occurred in tee.exe [4872]". My guess is that Vista doesn't want processes to pipe data back and forth, for understandable security reasons. Is this indeed what's going on, and is there any way to get this to run on Vista? Thanks in advance for your advice.
QRZ? de WAØTTN
This is my finally followup, and again I want to thank everyone who responded to my request for help. I haven't been able to meet up with the fellow who was having the problem yet, but in the meantime I realized I needed to have a "reference" Vista system around for just this type of issue, so I bought a fairly cheap Vista mini-tower at Office Depot last weekend. I finally had time today to test the project build out on the new machine today and guess what? It works just fine! So clearly the primary problem was that I was assuming it was a Vista related problem. It seems likely, at this point, that the fellow has a corrupted tee.exe file. We're meeting next week and should be able to get to the bottom of this. I'll report back, if anyone is interested in the final results. Thanks again for all your help. What a great bunch of folks here at CP! :cool: Dave
QRZ? de WAØTTN