We're having a very strange behaviour that I'm unable to identify a root cause for. We use TFS (2017.U2) to compile our legacy system, and are trying to update our build farm from 2008R2 up to 2016. The build system uses PowerShell (v5) to cycle through a list of VBP projects and run a VBS script to compile the projects.
First a bit of basics. UAC is totally disabled (in the registry, not just the slider control), VB6.EXE is also set to XP SP3 compatability, and also to run as the administrator.
Unfortunately, while we can see VB6.EXE start in task manager - it just hangs. Zero activity. Running the same compile interactively works just fine with the same user. This led me to theorize it was an environment problem, however process explorer shows me a valid user environment on the VB6.EXE process.
I don't believe this is due to VB6 throwing an error, as (at least in previous versions of Windows Server) when a background process opens a UI element, the OS indicates to the foreground that the background wants to break in. We dont see that.
We've stubbed this back to a bare minimum code example which I call "test.ps1":
$vb6="C:\Program Files (x86)\Microsoft Visual Studio\VB98\vb6.exe"
Set-Location D:\Builds\27\s\path\prjdir
start-process $vb6 -ArgumentList "/make /out errors.txt project.vbp" -wait
We've been using "start-process" to trigger the VB6 compiles because direct invokation via PowerShell doesn't ingest the parameters properly (they're actually built out of strings passed into the master script in the full blown process... this is the simplified version).
When run interactively (.\test.ps1) this functions properly. The project compiled and I get an errors.txt file written.
When started as a process (start-process .\test.ps1) this again functions properly.
When triggered via a TFS "PowerShell Script" task, this fails to complete the VB6 step - the VB6.EXE can be seen in the Task viewer with the appropriate arguments, and no CPU or IO is associated with the task. No errors.txt file is written. No new DLL is created.
I was able to dummy this down even further and remove TFS from the stack by running the test script from another machine. I ran a remote invokation of the script, and duplicated the result using this command:
PS C:\Users\svc_build> Invoke-Command –ComputerName TestBuild02 –ScriptBlock {powershell C:\Users\svc_build\desktop\test.ps1 }
Again, no errors.txt, and no new DLL. VB6.EXE starts up and just sits there. Process monitor doesnt provide any help in diagnosing what might be the issue.
This now smells of a security door being shut on me - even though the same domain user is running the same job, the difference is that this is a background process... and something is preventing a background process of executing in the same context as a foreground process.
Assuming this assumption is correct, can someone point me at the reason a remotely triggered (background) session isn't able to run VB6.EXE? (and of course, a work around for the situation would be appreciated :) )
If this is not a security issue - can someone identify the real culprit, and the solution to getting VB6 running as a background process, like we're used to seeing it run on W2K8R2?
I'm a bit late to the party, but this sounds like a very similar scenario to what I've just encountered.
Windows 10 v2004
UAC disabled
Compiling by running VB6.exe via a PowerShell script.
Using Bamboo as the build server, running as a Managed Service Account.
When running the build on the server via Bamboo, it hangs. When logging into the build server and running the build manually, it succeeded.
After cutting down the code I was able to reproduce a minimal failing case. The hang was caused by code in a UserControl's UserControl_Initialize method that was manipulating UI controls, but only when that UserControl was placed on a Form in the same project.
During compilation, the compiler will create an instance of the Form (why, I don't know), which in turn creates an instance of the UserControl, which in turn runs the UserControl_Initialize method. I can only assume that running the code at that point resulted in an error of some sort, and that resulted in the compiler hanging.
The same error can be caused by the UserControl_Resize event. That case is reasonably easy to fix by checking if Ambient.UserMode is true before trying to resize the child controls.
Private Sub UserControl_Resize()
If UserControl.Ambient.UserMode Then
' Position the child controls
End If
End Sub
Fixing the UserControl_Initialize methods required the code in those methods to be run at a different point (for example, when the UserControl is given the data to display, we now run the code that was previously in UserControl_Initialize).
Also worth noting is the compatibility settings for VB6.exe that we had to use. Using "Windows XP SP3" compatibility mode resulted in VB6.exe hanging immediately. We had to set it to not use any compatibility mode, but we did have to set Run this program as an adminisrtator, and had that applying for all users.
Related
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 have a very specific problem that I need fixing. The major issue is that I don't exactly know how to properly search the remnants of my problem on google. Therefore I am coming to StackOverflow for advice in hopes that someone will assist me.
Summary
So I am writing an application which is to be PCI-compliant for the company which I am starting. The application involves IPC (Inter-process communication) and two "watch-dog" apps which monitor the status of the main application. One of these "watch-dog" applications is an updater (sends an HTTP Request to the server looking for updates of the application).
So! This method which I am using to check the server if the application is up-to-date is using the WinInet library and InternetOpen() to send the request. Then read the response of the page and use GetCookie() to store the response in a buffer. It shall then parse the response accordingly.
If the response says that the current version of my application is less than the version located on the server. It will then tell the customer (user) that their application is out of date, and ask them whether or not they want to update the software. If they choose to update the software, it will perform a Download And Execute from the internet and launch the update-installer on the user's PC.
The Problem
Unfortunately, windows is very "secure" when it comes to having an "unauthorized" application send an HTTP Request to an outgoing url, let alone download something from the server then execute it on the users PC.
My conclusion to this issue was to add the watch-dog programs to the Task Scheduler. That way after the main application is run, it will spawn the watch-dog programs and check if they are running with NTAUTHORITY privileges (which are granted by the Task Scheduler).
After implementing the code to create the task and point it to the location of the watch-dog programs, naming it, writing a description and everything. I executed the program. It ran without errors though here the REAL PROBLEM:
1) Programs executes
2) Spawns watch-dog programs
3) Watchdog program checks for new version
4) Version is found
5) Installer is downloaded, execute ... but
6) The installer does not appear on the screen!
When I run my 'Process Hacker' application to monitor all process actions. I can see that the new installer is download & executed. It is running as NTAUTHORITY/SYSTEM just like the watch-dog programs but it doesn't appear on the system.
I made sure that in my code the status of the window is set to SW_SHOWNORMAL not SW_HIDE. I also made sure that all flags are set accordingly. Though it doesn't appear on the screen!
When I run the application without adding it to the Task Scheduler as my user without NTAUTHORITY/SYSTEM status and just regular user status. It executes (obviously since I am already running as administrator) -- everything works fine. But after adding it to Task Scheduler and having it run with SYSTEM level privileges. The window doesn't appear on the screen visually. Why's that?
I would greatly appreciate anyone that is able to assist me with this problem. Thank-you!
edit 1
Can anyone help me understand how this user applied his fix in the registry? By reading the problem I can somewhat interpret that he had the same issue as me.
App is invisible if started from Task Scheduler without any user logged in
In any case, I am trying to use the advice that Gisley gave me to run the application in Interactive Mode. Possibly going to try to give that a try. Still looking for more answers but I am going to be working no this none-the-less in the meantime.
edit 2
I tried setting the INTERACTIVE FLAG and it had no effect unfortunately.
Allow me to just emphasize my problem:
For example I write a program which has message boxes and put it in a loop.
for
message box
get current pid
make process in the task scheduler
spawn new process as the task scheduler proc with NTAUTHORITY/SYSTEM
kill last proc pid
end for
Then when I execute it:
I get the message box. Then after new process opens with NTAUTHORITY/SYSTEM the message box does not appear anymore.
Same for if I open a calculator for example.
System("cmd.exe start /c calc.exe")
Program runs... opens calculator
Program gets NTAUTHORITY/SYSTEM status
ON the next loop it executes the calc.exe
I see it in my task manager but it doesnt appear on the screen
I hope the above helped emphasize the core of my issue. I dont see the processes opened by the task scheduler process id with NTAUTHORITY/SYSTEM rights... I dont see the procs executed by it on my screen, though I see them in the task manager | process hacker and they are running with NTAUTHORITY/SYSTEM privileges too.
A shot in the dark - try running the task in interactive mode, but you'll need to have a user logged on.
https://superuser.com/questions/616206/run-interactive-task-even-if-user-is-not-logged-on-windows
Alternatively, or additionally, pass parameters to the installer so that it installs silently.
Silent installation of a MSI package
How can I start my program automatically if it crashes on windows 2003 server? Sometimes my program just crashes, is there a way in windows or settings that I can set?
There are several ways to create a process supervisor/guardian process on Windows.
First, is to leverage windows command line capabilities. Create a bat file:
#echo off
:start
start /w "your app to watch.exe"
goto start
start /w will wait for the process to exit. When the process crashes and exits, the bat script will relaunch it.
Another option is to use free supervisor tool https://github.com/chebum/Supervisor. It allows to restart the crashed app, plus it allows to monitor two or more apps at once and it will automatically close these apps when supervisor's window is closed.
The usual approach is to run what is known as a guardian process. This is a separate process, often a service, that monitors the state of the main process. When the guardian detects that the main service has died, it re-spawns it.
To the very best of my knowledge, there is not built in Windows functionality to do this for you.
Notice: running self-looping bat files can be useful, but unless you know what you're doing, they can wreak all kinds of havoc. This goes especially if you run them on startup. You have been warned.
Anyway. I just remembered something from my 286 days, when I played around a lot with BAT files. If you write the file
yourprogram.exe
some other event
the BAT file will run yourprogram, and then pause and wait around in the background until the program exits. After that it will run "some other event". This used to be kind of annoying if you wanted to run multiple things at once, but here it's actually useful. Using this, it's possible to make it run a loop that restarts the program (and reruns the bat file) as soon as it exits. Combine this with https://superuser.com/questions/62525/run-a-completly-hidden-batch-file, and you'll never even see it happening.
The final BAT file ("restart.bat" in this example) will look something like:
c:\[location]\yourprogram.exe
wscript "C:\[location]\invisible.vbs" "C:\[location]\restart.bat"
That's about it. Start the program (on startup via task or even just startup folder) with line 2, and this ought to solve your problem :)
Oh, if you want to stop the loop, just rename the bat file or put "// " in front of the two lines, save it, and exit the program.
If the program you are running requires admin rights, the solution I found was using psexec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) to run both the program and the bat with elevated privileges. In that case the BAT will look like:
c:\[location]\psexec -h c:\[location]\yourprogram.exe
c:\[location]\psexec -h wscript "C:\[location]\invisible.vbs" "C:\[location]\restart.bat"
Then you run the bat as administrator, or run the second line (without the psexec part) from task scheduler with elevated privileges. BEWARE: running it as a normal user and clicking "no" on the UAC prompt gave me a BSOD, probably because it looped "can't run program because of lacking privileges" a couple of billion times or something :)
You can use RegisterApplicationRestart.
"If you register for restart and the application encounters an
unhandled exception or is not responsive, the user is offered the
opportunity to restart the application; the application is not
automatically restarted without the user's consent. "
For automatic restart without user intervention, there is also RestartOnCrash. Works with all Windows versions.
I was looking for something similar. There are two options to handle this - either you can write a small script by yourself or use something that is already existing.
After some googling I came across this nice list. The blogger has compiled about 8 tools to automatically restart a crashed or closed application.
Unfortunately there are no settings in Windows to automatically restart a regular program when it crashes.
Do you need to actively interact with your application's GUI? Some of the Service Wrappers (designed to run any application as a Windows Service) will monitor your application and restart it when it fails, but be sure investigate Session 0 Isolation to ensure that it won't get in the way.
You may use some special app like BDV SystemEvents or any other. It allows you to specify application which will be started if some another application is closed. Specify the same application as a Condition and as an Action and you will get expected results.
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?
We are using VS 2008 Team System with the automated test suite, and upon running tests the test host "randomly" locks up. I actually have to kill the VSTestHost process and re-run the tests to get something to happen, otherwise all tests sit in a "pending" state.
Has anyone experience similar behavior and know of a fix? We have 3 developers here experiencing the same behavior.
This may be related to an obscure bug that causes unit tests to hang unless the computer name is UPPERCASE. Crazy, I know - but I had this problem and the fix worked for me.
Bug report on MS Connect
Workaround on MS Connect
TFS Blog Article about this issue
HowTo edit the registry to change your computer name
The easiest approach is to tweak the registry. You need to edit two keys:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName
Change value ComputerName to be upper case in both keys, and restart. Tests then magically work.
When you say lock up, do you mean VS is actually hung, or do the tests not run?
The easiest way to track down what is going on would be to look at a dump of the hung process. If you are on Vista, just right-click on the process and choose to create a memory dump. If you are on Windows XP, and don't have the Debugging Tools for Windows installed, you can get a memory dump using ntsd.exe. You'll need the process ID, which you can get from Task Manager by adding the PID column to the Processes tab display.
Once you have that, run the following commands:
ntsd -p <PID>
.dump C:\mydump.dmp
You can then either inspect that dump using WinDBG and SOS or if you can post the dump somewhere I'd be happy to take a look at it.
In any case, you'll want to likely take two dumps about a minute apart. That way if you do things like !runaway you can see which threads are working which will help you track down why it is hanging.
One other question - are you on VS2008 SP1?
I would try running the tests from the command line using MSTest.exe. This might help isolate the problem to Visual Studio, and at least give you some method of running the tests successfully.