I am having some problems with a app we are making with wxWidget/wxPython and PyInstaller.
We have compiled the app into a single exe for windows but:
1) On some machines it will not launch at all. It doesn't generate a error or anything in the app logs. It just stops almost immediately.
2) On some machines it will launch fine from cmd but not from explorer. again, same behavior. It just stops almost immediately. I don't even see it pop up in the process explorer.
3) On some machines it works just fine.
Are there any tips on how I can figure out what is going wrong? Is there a way to launch a exe with a debugger?
There are a few things you may want to look into:
Did you compile it as "one file"? I have heard that one exe may be blocked by some antivirus programs. It uses a few of hacks to get everything in one executable which may be considered malicious.
Did you compile it as Windows app (no console)? You may want to enable console and run it on machine where it does not run at all from console. That way you may see why it crashes.
Related
I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.
I've been fighting this little problem for a while now, so I'm really hoping I can get some help. I've been looking for a solution to this, and I found this SO question: Debugging doesn't start.
My issue is somewhat similar to the issue discussed here, except that my issue is a two-parter.
Part 1: Similar to the issue discussed on the other question. (Debug Window Doesn't show up)
When I attempt to launch my Windows 32 console application project (The simple kind that opens in the windows CLI). The CLI (or CMD) window doesn't open, and windows idles giving me a spinning cursor wheel. Visual Studio IDE (I'm using VS 2013 Community) becomes unresponsive and I cannot access any menus, or use any hotkey to "Stop Debugging". One difference from the provided SO question though, is that when I try to launch "MyProject.exe" from my project's "Debug" folder I get the same result as attempting to debug in the IDE.
Part 2: Unkillable Process
When I try to close my debug application in the windows task manager, it is not listed as an ongoing process. However, whenever I try to manipulate, delete, or otherwise modify my Project.exe application (in my Project's "Debug" folder), windows informs me that the application is in use. Confused by this, I downloaded two applications. The first was Process explorer, which showed me that I did in fact have 2 instances of "MyProject.exe" running. The second was Process Hacker, which also showed me 2 instances of "MyProject.exe". However, neither of these programs were able to terminate either of the "MyProject.exe" processes.
I am capable of terminating the processes for visual studio and restarting the IDE, however, because the "MyProject.exe" processes are still running. Building always fails with the error
"Error 1 error LNK1168: cannot open C:\Users\Brandon\Desktop\MyProject\Debug\MyProject.exe for writing"
Whenever I restart my computer, the lock files (as expected) are removed, and the "MyProject.exe" processes disappear. I can restart VS and everything works, but if I try to Debug (pressing "Start Debugging" or F5) the same issue occurs.
A process of my program is started ("MyProject.exe"), but the CLI window where my program's text should appear doesn't show up. Visual studio locks up, and "MyProject.exe" persists until the next restart because "MyProcess.exe" cannot be terminated.
My solution configuration is set to "Debug", Solution Platforms = Win32.
I have tried creating a new blank console project in VS 2013 and I get the same result: code builds fine, but I have the same debugging issue. I get an identical result with a quickly assembled "Hello World" project.
Sorry for being a noob, but honestly. I really don't know what's going on, so any help is greatly appreciated.
(Note: Running Windows 10 with VS2013)
EDIT (UPDATE):
So, I'm having the same problem with several programs in Windows 10 (most notably Allegorithmic's Substance Painter). So it looks like this may actually be an OS problem. Several of my programs whenever I try to launch them do the same thing...the program acts like it's going to launch, but then no usable window appears. Looking at my processes I can see that the process has been started, but it is once again unkillable. For reference, I am using Windows 10 Version 1511 (OS Build 10586.17).
I believe your problem might be Avast, if you are running it. I had exactly the same issues until I uninstalled it. Had upgraded to Win10 and VS2013 just froze, same as you described.
Cheers.
I've added some code to the Windows Filtering Platform MSNMNTR sample for my own application, but it still has the same structure. I've compiled the driver and the application for Win8 64-bit and production-signed the driver. On the (virtual) machine that I built the code on, the sample works fine and monitors correctly. When I copy the inf, sys and exe to another machine, the sample does NOT monitor. Through traceview output, I can see that on the second machine, DriverEntry() is not called, therefore the flow controls are never set up. The two machines are running the release version of Win8. It doesn't appear to be an issue with my new code, since the driver works fine on machine #1, and it doesn't appear to be a signature problem because when I turn off signature enforcement on machine #2 I still have the problem. Both the release and debug versions of the code have the same issue. The steps I use to set up and run the code are below. What are some things that might cause this behavior?
Copy driver .pdbs to a folder for traceview.
Right-click .inf and choose "Install"
Run "net start msnmntr" from an elevated command prompt.
Start traceview as administrator.
Run "monitor monitor "C:\Program Files\Internet Explorer\iexplore.exe"" from an elevated command prompt.
P.S. I haven't put windbg on this yet, but I will update the question with the results as soon as I try it.
Edited to add: OK, I ran the kernel-mode debugger on both machines and saw a difference in behavior. First of all, DriverEntry does get called on both machines. I was mistaken about that. However, on the machine where the code works (i.e. monitors web traffic) DriverEntry gets called when monitor.exe is run (step 5 above), and on the machine where the code does not work DriverEntry gets called when "net start msnmntr" (step 3 above) is executed.
The problem was that I had not installed the callouts via "monitor addcallouts" on the second machine. Since this is a one-time step, I had forgotten I did it weeks ago on the original machine.
Switched development to 64bit windows and I'm having an issue. After I quit the executable it is still locked for at least 5min and sometimes until I reboot. So I can't do a new build, which makes development a little slow and frustrating.
Filelock reports it to be locked by "system" (helpful) and can't unlock it, even running as admin. It doesn't appear to be runni=ng in procexp or taskmanager.
This is a C++ app using Qt, with vs2010 pro on Windows7 pro 64bit - not sure if any of those are the problem, it was fine on 32bit.
Has anyone else seen anything like this?
I frequently have similar problems, which in my case are caused when I'm debugging an application that uses a MIDI device. If the app crashes or I stop debugging (ie stopping in the debugger, rather than letting the app finish normally) then one driver on my system doesn't release the device. The process resists all attempts to kill it. Either I have to disconnect the device temporarily (so the driver gets released) or reboot. As a workaround I can usually just rename the .exe which means that I can link again, though I end up with lots of zombie processes.
So the first thing to check is whether there are any particular I/O devices you're using in this app, and whether the drivers are up to date. If you don't think there's any specific drivers you're using then try running windbg, attach to the process and type !analyze -v -hang. This may tell you which driver dll it's waiting on.
Probably a stupid idea- But try changing the file ownership to you again, and turn on "Take Ownership" in the file system settings.
It is annoyingly common to own a folder, and not all the files inside it.
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?