I've used YouTube-dl successfully on my mac for quite some time.
I downloaded YouTube-dl.exe (after downloading Microsoft Visual C++ I was told a newer version already exists on my computer - it also says Python is not required), but when I launch the executable, it briefly opens a command line window but then closes immediately and nothing else happens. I've tried Googling and even went to the IRC support chat (who turned out to be more rude than helpful) to no avail. Any ideas what to do?
youtube-dl is a command-line application. To use it directly, start a terminal windows by pressing Win+R, and entering cmd. To get to know the command-line interface, you probably want to consult a tutorial.
If you were looking for a graphical application, use one of the graphical frontends instead; for instance, youtube-dlg.
Related
Whenever I ask for the user input (using C or C++), VS Code will open my windows terminal, ask for input, and then close and ask for the same input in the integrated VSC terminal.
Now, this should be a very simple fix but no matter what I google, I can't find anyone having the same issue.
Also, when I enter input into the windows terminal, it doesn't use that information at all. It just closes after all of the console input operations are complete. Only the VS Code's integrated terminal does anything useful.
Anyways, does anyone know how I can disable my windows terminal from opening up when running C/C++ programs?
Tried googling for help but couldn't find anything directly related to what I was experiencing
Good day, colleagues. I'm building an application using OpenSSL - the application crashes with an error code: 0xc0000142.
The standard application openssl.exe also crashes with this error code. What could be the trouble?
According to Microsoft Support in KB 2701373:
This issue is caused by an error in the
Microsoft.powershell.consolehost.dll file. When a Windows PowerShell
script calls the Console.Write method, or when you run an executable
file for an application from a Windows PowerShell session, values are
written into the PowerShell console. Additionally, a corresponding
console handle is created. When many console handles are created, the
console handles leak, and the issue that is described in the
"Symptoms" section occurs.
There's also a question in the Microsoft Communities, CMD.EXE error 0xc0000142, and the answer appear to be "reinstall your application".
I'm not sure how MinGW affects the problem. Since MinGW is abandoned, I'm guessing its the problem and you likely won't be able to fix it. Its probably providing an old, buggy version of something with ABI problems.
Maybe you can use Cygwin for Linux on Windows. Cygwin is still actively developed and maintained.
I see the following error whenever I try to debug "Cross Platform" under "C++" category: "Unable to start debugging. Unexpected GDB output from command "-target-select remote :5039". Remote connection closed"
I've installed all of the contents when I downloaded Visual Studio 2015 community and I ran it on Windows 10 Pro which supports Hyper-V.
I've been searching a solution for this and I've found an assumption:
"What is your debug target, the VS Android Emulator? When we saw this before it turned out to be a bad emulator image. Do you have this problem with all targets (e.g. if you try a physical device) or just one?"
In my case, I just tried this via Emulator(VS Emulator 5" Lolipop (5.0) XXHDP Phone (0x86 -...)
So I've sent an Email to VS 2015.
And the answer was like this:
"Sorry for the delay in responding we were looking at an emulator image of another user that ran into this problem so I was waiting until we had the results of that investigation to report back. We actually were not able to find anything wrong the emulator itself, our current hypothesis is that it is a network or adb problem interfering with GDB’s ability to connect to GDB server on the remote machine. Do you see this error every time you try to debug, or if you reboot the emulator will it work sometimes right after the reboot? Next time you see the error, can you open the emulator’s console mode by going go the Hyper-V manager and double clicking the emulator. Then find the location your app installed to and run “gdbserver --version" from the app path and let me know what it says? This will validate if the correct version of gdbserver is on the device."
So we are trying to solve this problem but I'm also asking here just in case.
Is there anyone who has magical solution for this problem?
I'll put a comment on this if I figure out how to solve this.
Thanks in advance.
** Following answer is from the manager of Visual Studio 2015:
You are only the second person who has run into this issue, and the first person that ran into it provided their everything works correctly when we run their .vhd on our machines so it appears to be some strange problem where gdbserver (which comes from the Android NDK provided by Google) crashes only when running on certain machines. Unfortunately the .vhd you provided does not appear to be the correct one it won’t boot for me. You can see the .vhd file being used by the emulator if you look under the settings of the emulator in your Hyper-V manager. .However given we got the other person’s .vhd you can hold off providing any additional information at this point. I’m waiting to hear back from the emulator team on if they have any ideas since this appears to be an issue only on specific machines since.
If you don’t mind my asking, if you don’t have a background in computers what inspired you to try C++ on Android? That scenario will be significantly more complicated than doing Java on Android.
It's been almost two months since I got this answer but I haven't got any additional response from them yet. So, I ended up quitting developing an application by using VS2015.
If you run into this problem, there are only two ways to go. Change your computer or stop developing application via VS2015.
If the project name contains spaces, the whole remote debugging fails. Visual Studio also creates weird paths. When checking out the "Blink1 for Raspberry Pi" template, I named the Project "Blink1 for Pi", which resulted in a path like this:
~/projects/Blink1?/for/pi/PI/for/pi....
And all the debugging failed. When I recreated this keeping the project name "Blink1", everything worked fine. It's a pity, that spaces aren't handled here...
It's my first device driver for Windows and I followed the step-by-step instructions at http://www.adp-gmbh.ch/win/misc/writing_devicedriver.html but my device driver doesn't start at windows boot and also the event viewer shows an error and when I click on the error in the event viewer the thing crashes. When I start the driver manually after windows boot it works. Is this tutorial incomplete? I already found the sources in the internet but not at this site and I think I found an error in his sources, too, he just forgot to add a header file to the "Writing Events from a Device Driver. I can compile it without any errors in DDK.
Yes, this tutorial is incomplete and very old. Install WDK and follow one of WDK samples, written using plain WDM, or better, KMDF. Driver installation should be done using .inf file, and not by manual Registry editing.
If you still want to know why this driver doesn't start, debug it. Possibly its DriverEntry or CreateCamel function fail from some reason.
Another thing you can do without debugging, is to add a lot of KdPrint statements to the driver, and watch them using WinDbg, or DebugView.
Gosh, this is so weird, I don't know what to say. The short version is that I have a simulator app which I spawn from my application when the user asks me to. It recently stopped working, though I can run the simulator fine from the command line or Start menu. This could be due to moving to VS2010 or Windows 7 or something I didn't notice reviewing source control diffs.
I have a second simulator which I try to spawn in the same fashion and it works fine.
By default, I'm using Qt3's QProcess wrapper around CreateProcess for this purpose, but I get the same behavior using system, my own CreateProcess, and ShellExecute.
ShellExecute of a cmd.exe "/c application params" does provide me with some more information however. I get the dialog
"The program can't start because MSVCR80.dll is missing from your computer. Try reinstalling the program to fix this problem."
Inconveniently, both the parent application and the second simulator use MSVCR80.dll.
Upon copying MSVC*80.dll from g:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5 to the same directory as my executable, the error message changes to
"Runtime Error!
Program: g:\path\to\app.exe
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
Followed by
The application was unable to start correctly (0xc0000142). Click OK to close the application.
And, once again, the application runs fine from the command line with those dlls in place.
Update:
I suspected perhaps it was environment related, so changed my ShellExecute mechanism to do cmd /c set && app params. I set up a cmd.exe with those same params and my app is now crashing similarly. Will update when I figure out why :)
It is MATLAB's component runtime tool that is modifying my process's PATH variable to bad effect. It is prepending its own dir full of dll's and wreaking havoc.
A foolish tool I was using did a setenv on PATH, prepending a directory it wanted for dynamically loading some dlls, but which messed up my application later. I ended up using GetEnvironmentStrings as shown in the last example here, erasing the first entry in the PATH env var, and sending the new (original) environment to QProcess, which wraps CreateProcessA.
You need to install the CRT
This may work - if it breaks, you get to keep both pieces :-)
Try installing VC++ redistributable from here - http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en.
Remember to backup your system, create a restore point etc. before installing stuff.
Another idea -try reinstalling the failing appliacation itself. It may come with its own copy of VC++ redistributables, and reinstalling might help. Esp. trying to reinstall it using Windows 7's compability mode (perhaps go back to Vista or XP compatibility) might be even more effective.
To reiterate - you'll have to try, and I've no real idea if either of the above ideas will do you good, or even be sure to do no harm. That said, if I were faced with a similar problem, these are the steps I'd try. HTH!