Help Needed Converting VB6 OpenProcess to .Net - Process Execution Speed

I am trying to convert an application from VB6 to VB.net which essentially deploys windows images in a WinPE environment. We are moving from VB6 WinPE 3.0 x86 to VB.Net WinPE 4.0 x64 and our imaging application needs to be upgraded accordingly. The majority of coding is done, but there is an issue regarding speed of image deployment that I cannot seem to find the answer to.

The VB6 code deploys images via calling ghost32.exe and passing it some start-up parameters. Essentially this is just the ghost image file location and several other constants. Firstly I thought there could be any number of differences between WinPE 3.0 and 4.0, x86 and x64 and even VB6 to Vb.net. However, when I manually input the command string into shell in the old existing environment the speed is also slow. So I need to understand why when executed via the old Vb6 code does the deployment speed almost double.

Any help would be appreciated :)

Code:

---

Private Declare Function ShellExecute Lib "shell32.dll" _
    Alias "ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, _
    ByVal lpFile As String, ByVal lpParameters As String, _
    ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" _
    (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
   
Private Declare Function SetWindowPos Lib "user32" (ByVal hWnd As Long, _
    ByVal hWndInsertAfter As Long, ByVal x As Long, ByVal y As Long, _
    ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
   
Private Declare Function GetDesktopWindow Lib "user32" () As Long
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
'END WINDOWS

---

The basic sub is :

Code:

---

       
 If FileExists("V:\Install1.GHO") = True Then
            frmSplash.lbl_progress.Caption = "Deploying test image..."
            lngTaskID = Shell("X:\Windows\System32\ghost32.exe -clone,mode=restore,src=""V:\Install1.GHO"",dst=1 -sure", vbMinimizedNoFocus)
                Do
                lngPID = OpenProcess(PROCESS_QUERY_INFORMATION, False, lngTaskID)
                DoEvents
                CloseHandle lngPID
              Loop Until lngPID = 0
              Call createReport
               
                If bPass = False Then
                    erri = MsgBox("MODEL SERIAL FAILED" & vbCr & "PLEASE CHECK MODEL/SERIAL/ASSET IN BIOS", vbCritical, "MODEL/SERIAL/ASSET ERROR!")
                   
                    lngTaskID = Shell("X:\Windows\System32\wpeutil.exe shutdown", vbHide)
                  Do
                    lngPID = OpenProcess(PROCESS_QUERY_INFORMATION, False, lngTaskID)
                    DoEvents
                    CloseHandle lngPID
                  Loop Until lngPID = 0
               
                End If
               
                erri = MsgBox("Test image deployed. Click OK to restart", vbOKCancel)
               
                If erri = vbOK Then
                  lngTaskID = Shell("X:\Windows\System32\wpeutil.exe reboot", vbHide)
                  Do
                    lngPID = OpenProcess(PROCESS_QUERY_INFORMATION, False, lngTaskID)
                    DoEvents
                    CloseHandle lngPID
                  Loop Until lngPID = 0
                Else
                    Unload frmSplash
                    Exit Sub
                End If
        End If

---

It would be better to check the exit code of the target process (via GetExitCodeProcess) rather than testing the process handle returned by OpenProcess. See this thread for a VB6 example.

Thanks :)

However this old code is being replaced completely. The problem is to be viable the deployment time must be equal or better to the old 32bit VB6 system.
I need to find out why when the above code is run, the windows 7 ghost deployment is almost twice the speed as executing it manually via shell.

Once the reason is found hopefully I can implement a similar method in .net as currently the system.diagnostic.process is also slow :(

The VB6 code you posted is waiting for the shelled process to terminate before moving on to the next. It checks the process handle to determine whether the process is still alive or not. However, that method is quite inefficient. As I've stated, it's better to check the exit code instead. If you do that, you might even see a tiny speed improvement from the loops.

I must admit I know nothing about ghost32.exe, so I also don't know why it would run faster or slower depending on the method of invocation used. Sorry I can't be of more assistance...

Yes I understand. The new .net process is coded as you suggested, but unfortunately for some reason runs very slowly (approx half the speed).
Ghost32 is just a tool that clones HDDs and deploys the stored backups. The process takes 5-10 minutes depending on the size of the backup.

I am completely at a loss to work out how this old method is quicker than simply entering the same string into shell :(

Thanks again for the help.

Quote:

---

Originally Posted by MarkW1976

Yes I understand. The new .net process is coded as you suggested, but unfortunately for some reason runs very slowly (approx half the speed).

---

Well, that is strange. Opening and closing a process is supposed to be slower than just checking its exit status.

Quote:

---

Originally Posted by MarkW1976

Ghost32 is just a tool that clones HDDs and deploys the stored backups. The process takes 5-10 minutes depending on the size of the backup.

---

I see.

Quote:

---

Originally Posted by MarkW1976

I am completely at a loss to work out how this old method is quicker than simply entering the same string into shell :(

---

Can you clarify what you mean by "shell"?

Sorry I mean command prompt. If I enter the same string as "X:\Windows\System32\ghost32.exe -clone,mode=restore,src=""V:\Install1.GHO"",dst=1 -sure" the backup takes twice as long to install.

That is really perplexing. I can't see why your VB6 code would be any faster than doing the same from the command prompt.

Anyway, in case nobody else chimes in soon, you may want to ask the moderators to move your thread to the VB.Net forum. Just click on the black triangle icon near the bottom left side of your OP. Good luck!

Quote:

---

Originally Posted by Bonnie West

That is really perplexing. I can't see why your VB6 code would be any faster than doing the same from the command prompt.

Anyway, in case nobody else chimes in soon, you may want to ask the moderators to move your thread to the VB.Net forum. Just click on the black triangle icon near the bottom left side of your OP. Good luck!

---

Thanks for all your help! I'm at a loss to explain what is going on, but at least I can take comfort in the fact I'm not missing anything obvious! haha :)

I see two possibilities (this is without having any real idea of what ghost.exe does, by the way):

1. This may be obvious, but just in case, can you confirm the results of the VB6 execution, .net execution, and shell execution of the EXE are all identical? I am wondering if maybe more work is being done with the .net and shell calls somehow.
2. What does the "vbMinimizedNoFocus" flag do with relation to this EXE? What happens to the execution if you remove that flag? I wonder if this flag basically causes the execution of the program to not have to wait for graphics page to refresh before moving on, allowing it to run significantly faster.

maybe, as I saw in the example some network storage like V:\

I remember working with an app made in FOXPROT, in some office was 2 CPUs, one acting as the HOST of the DB (the soft cliente hosts the DB), and the other CPU (its soft client is linked to the first soft client).

the problem comes when the officeman closes the DAY's work, if commanded from the client that is not hosting the DB, it takes a LOOOONGGG wait to process all todays DB. And he claimed that the system is too slow!.

Anyway, telling, No, close the today's work using this CPU, the process was fast as just few seconds.

In about copying files in Windows over the LAN is the same, bah close to be the same.

If the remote CPU is being READED, is faster.

If the remote CPU is being WRITEN, is slower.

But if you takes the actual "remote CPU" and command the COPY function from there, it will be FASTER, as it becomes the LOCAL, and the remote CPU will be just READED.

Quote:

---

Originally Posted by Lenggries

I see two possibilities (this is without having any real idea of what ghost.exe does, by the way):

1. This may be obvious, but just in case, can you confirm the results of the VB6 execution, .net execution, and shell execution of the EXE are all identical? I am wondering if maybe more work is being done with the .net and shell calls somehow.
2. What does the "vbMinimizedNoFocus" flag do with relation to this EXE? What happens to the execution if you remove that flag? I wonder if this flag basically causes the execution of the program to not have to wait for graphics page to refresh before moving on, allowing it to run significantly faster.

---

1) As far as I can tell everything is identical. The ghost function this code calls can be thought of as extracting files from a .zip and writing them to the HDD. Once the process is completed there is a Windows 7 OS on the drive, which is extracted from the same backup for each method.
2)I was thinking something along the same lines, this is definately worth investigating. I will run a few tests and post some results later.

Thanks for the tip.

Quote:

---

Originally Posted by flyguille

maybe, as I saw in the example some network storage like V:\
But if you takes the actual "remote CPU" and command the COPY function from there, it will be FASTER, as it becomes the LOCAL, and the remote CPU will be just READED.

---

Unfortunately I have no control over this. The Ghost.exe must run on the target computer. Thanks for the information though, this might come in handy in future :)