Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / December 2003

Tip: Looking for answers? Try searching our database.

Win2k Hyperthreading .Net & Processes: ODD!

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
smith - 07 Dec 2003 08:57 GMT
I was recently set to release an app that used very common single instance
code and hit the oddest issue.

After many hours of full build tests I believe that it is duplicatable.

Environment:

.Net 1.1 (v1.1.4322)
Windows 2000Pro
HyperThreading machine

Issue:

Install 2kPro on the HT box (I use an MSI-based 3.06Ghz), fully install all
Windows Updates.

Create a .Net app using the single instance code based on
Diagnostics.Process.GetProcessesByName(Diagnostics.Process.GetCurrentProcess
.ProcessName)

Install the application on the 2k box & run it.

If the code is called in the Load even to a form you will get a "Couldn't
get process information from remote machine" exception.  The exception dump
will mention  not being able to get the process "ticks"

If the same code is called from a sub main rather than from a form_load then
you will get an "Unhandled Exception occurred" error.

Now, here's where it gets weird:  Restart the machine and get into the BIOS.
Disable Hyperthreading and get back into Win2k.  Run the app.  It runs fine.
Minimize it and try to start a second instance and the first instance pops
up to the top of the order and the second instance dies.  Perfect.

Now, restart and go back into the BIOS and turn HT back on.  Get back into
Win2k.  Run the app.  It runs fine in every way.

NOW: Go back into the BIOS and turn HT back on.  Get Back into Windows and
run the app.  It Runs Fine.

Weirder still:  Uninstall the application, search the machine and make sure
that it's gone.  Restart the computer.  Reinstall the app (Hyperthreadin
still ON).  Run the app.  It runs fine!

Format the drive and fully reinstall Win2k Pro then the app.  It starts all
over again.

I could understand this if the app continued to run after turning HT back on
the first time ... from my level of understanding that could be because
without HT the code could fully execute and so it got compiled for the
machine and later with HT turned back on the code was already compiled.

But why is it that after uninstalling the app fully, and just reinstalling
the app "fresh" the code runs? (And, another test app using the same code
also now runs)

XP Home and Pro have no such issue with the code with or without
Hyperthreading, it's just 2k.

I've seen a couple of mentions of the "Couldn't get process information from
remote machine" exception related to HT, but none of these few say anything
about switching HT off then on again as a fix.

Here is one of the few mentions:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=551a01c37d39
%24cbad0e70%24a501280a%40phx.gbl&rnum=13&prev=/groups%3Fq%3D%2522Couldn%27t%2Bge
t%2Bprocess%2Binformation%2Bfrom%2Bremote%2Bmachine%2522%26hl%3Den%26lr%3D%26ie%
3DUTF-8%26oe%3DUTF-8%26start%3D10%26sa%3DN


Can a framework or lower-level expert shed some light on why all this might
be? I'd love to hear the logic.

(I'm converting the code to use a Mutext because it appears the crux of the
matter is in the use of GetCurrentProcess.ProcessName)

Fyi:  here is the code, it is fairly common:

''Declarations: (excuse the "straight style", it is for this test)

Public Const SW_NORMAL = 1
Public Const SW_MAXIMIZE = 3
Public Const SW_RESTORE = 9
Public Const HWND_TOP = 0
Public Const HWND_TOPMOST = -1
Public Const HWND_NOTOPMOST = -2
Public Const SWP_NOMOVE = &H2
Public Const SWP_NOSIZE = &H1

   Declare Function ShowWindow Lib "user32" (ByVal hwnd As Integer, _
ByVal nCmdShow As Integer) As Integer

   Declare Function ShowWindowAsync Lib "user32" (ByVal hwnd As Integer, _
ByVal nCmdShow As Integer) As Integer

   Declare Function FindWindow Lib "user32" Alias _
"FindWindowA" (ByVal lpClassName As String, _
ByVal lpWindowName As String) As Integer

   Declare Function SetWindowPos Lib "user32" (ByVal hwnd As Integer, _
ByVal hWndInsertAfter As Integer, ByVal x As Integer, _
ByVal y As Integer, ByVal cx As Integer, ByVal cy As Integer, _
ByVal wFlags As Integer) As Integer

   Sub main()
       If HasPrevInstance() Then
           Exit Sub
       Else
           Dim fMain As New Form1
           fMain.ShowDialog()
       End If
   End Sub

   Private Function PrevInstance() As Boolean
       If

Diagnostics.Process.GetProcessesByName(Diagnostics.Process.GetCurrentProcess
.ProcessName).Length > 1 Then
           Return True
       Else
           Return False
       End If
   End Function

   Private Function HasPrevInstance() As Boolean
       If PrevInstance() = True Then
           ' Get all previous instances
           Dim Processes() As Process
           Processes =
Diagnostics.Process.GetProcessesByName(Diagnostics.Process.GetCurrentProcess
.ProcessName)
           ' Activate the first instance
           Dim temphwnd As Integer
           Dim x As Integer
           Try
               For i As Integer = 0 To Processes.Length - 1
                   temphwnd = Processes(i).MainWindowHandle.ToInt32
                   x = ShowWindowAsync(temphwnd, SW_RESTORE)
                   'bring it to the top of the z-order
                   SetWindowPos(temphwnd, HWND_TOPMOST, 0, _
  0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE)

                   SetWindowPos(temphwnd, HWND_NOTOPMOST, 0, _
  0, 0, 0, SWP_NOMOVE Or SWP_NOSIZE)
               Next

           Catch ex As Exception
 'Todo: Replace for release
               MsgBox(ex.ToString)
           End Try
           Return True
       Else
           Return False
       End If

   End Function

-robert smith
kirkland, wa
smith - 07 Dec 2003 09:37 GMT
Oh, not "unhandled exception"  but one of those fun "UnHandle-Able"
exceptions :)  I'll spend the 3 hours again resetting the machine (again)
and wrap in a try...catch, might get the "remote machine process" exception
that way.

But the question remains valid.

-s
>>> Previous
Mark Hurd - 12 Dec 2003 11:17 GMT
Given what you describe, if it /is/ repeatable, I'd guess there's some
hardware dependent JIT bug (or a JIT difference that highlights the bug), but
it would have to automatically persist the JIT code (or some configuration at
least) for the scenario you describe.

To attempt to confirm this, check the GAC details regarding the native images
(NGENed asseblies) to see if there's changes.

Alternatively, a non .NET variation is only being highlighted by your code.
Try locating all changed files between when it occurs and when it doesn't.

Please post to the newsgroup any further results.
Signature

Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)

Gang Peng - 16 Dec 2003 07:05 GMT
I have replied to the message on another group (performance.)
Please check for answer there.
Thanks,
Gang Peng
[MS]
> Given what you describe, if it /is/ repeatable, I'd guess there's some
> hardware dependent JIT bug (or a JIT difference that highlights the bug), but
[quoted text clipped - 8 lines]
>
> Please post to the newsgroup any further results.

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.