Exception when use MessageBox.Show in prog with long path

  • Thread starter Thread starter Jeff Pek \(Autodesk\)
  • Start date Start date
J

Jeff Pek \(Autodesk\)

All -

I haven't come across this issue elsewhere, or in a search within this
newsgroup. Perhaps someone here has come across it...

In both 1.1 (SP1) and 2.0, when using MessageBox.Show in a simple Windows
app (only shows the messagebox), and with the .EXE file sitting at a
location where its total path length is greater than 128 characters, the EXE
doesn't work.

In .NET 1.1, a NullReferenceException is thrown inside MessageBox.ShowCore.
In .NET 2.0, nothing at all happens (the app just exits). Even with all
exceptions set to be trapped in the debugger, there's no exception at all.

If the same .exe is moved to a higher-level folder, such that its total path
is less than 128 chars, it works fine.

Any clues?

Thanks,
Jeff
 
Jeff,

I wasn't able to replicate your issue with 1.x, I created a folder
test/tttt(x128) to create a path that matched your criteria. Placed the
application exe in the folder, executed it, and my button displayed the
msg box.

Are you doing anything differently? Perhaps post the code?

Regards

John Parrish
 
Thanks, John. I'll try a simpler path (i.e., without spaces), and if it
still repros, I'll post the code.
- Jeff
 
Oddly, as I test this again, now it doesn't seem to be related to the
current directory, but rather to the directory where the EXE is. If I copy
the EXE to the path below, and run it, the problem occurs. However, if I CD
to the directory, but run it from elsewhere, it's fine. I could have sworn
it behaved differently once, but hey, it's Sunday...

Thanks,
Jeff
 
I moved this EXE to another machine, into a similar path, and it worked
fine. So it seems to be related to the configuration of my dev box, for some
reason. I'll try installing .NET 2.0 on the other box to see what happens...

jp
 
So much for that theory .... .NET 2.0 is already installed on the other box.
Back to the drawing board...
- jp
 
Hi Jeff,

We too are seeing similar errors over here with a 1.1 app. I have a
set of unit tests that run for my apps, and they of course work just
fine on my machine, the build machine, and other peoples' machines.
The other day one of our devs reported that the unit tests were failing
for him as soon as one of our windowed apps started. The underlying
error was this:
System.NullReferenceException: Object reference not set to an instance
of an object.
at System.Windows.Forms.SafeNativeMethods.ShowWindow(HandleRef hWnd,
Int32 nCmdShow)
at System.Windows.Forms.Control.SetVisibleCore(Boolean value)
.....
at System.Windows.Forms.Control.Show()
....
(My form's constructor)

As soon as I did a search on this, I saw a pattern. A number of people
were seeing this same with no explanation, but I found one or two
mentions of people fixing it by shortening the path in which the app
ran . Sure enough, our unit tests end up running under a very deep
structure, so I had him shorten his development path and the problem
vanished!

Fast forward two weeks to today. The same dev has the same problem
again. He tries shortening his path even further, and that doesn't fix
the problem. He continues to get the NullReferenceException! Then to
debug it, I go in and begin to run the exe directly. A bit of
background here. As part of our unit tests, 3 related executables are
compiled and placed in the same directory. I run the first one a few
times and don't get the error. I run the next on and get the error
twice in a row. I run the 3rd one and don't get the error at all.
These apps are EXTREMELY similar apps. The code inside is in fact
identical - Only some data in their resource streams are different. I
try renaming File1 to a longer name and that doesn't cause the error.
Renaming file2 to file1 causes it to begin working again! Then I play
around with renaming a bit more and think I determined the name didn't
have anything to do with it, but it seemed related there for a while...
Eventually we can't get the error to reliably on any of the apps. All
of them manifest it at some point or another. Then we gave up on the
name idea and begin trying to run the same app as quick as we could.
The less time that passed between runs, the more likely it was to
produce this error. Then we would occasionally see even stranger
things. The app would start fine, but the MessageBox it pops up would
cause the following, related error:

System.NullReferenceException: Object reference not set to an instance
of an object.
at System.Windows.Forms.SafeNativeMethods.MessageBox(HandleRef hWnd,
String text, String caption, Int32 type)
at System.Windows.Forms.MessageBox.ShowCore(IWin32Window owner,
String text, String caption, MessageBoxButtons buttons, MessageBoxIcon
icon, MessageBoxDefaultButton defaultButton, MessageBoxOptions options)
at System.Windows.Forms.MessageBox.Show(String text, String caption,
MessageBoxButtons buttons, MessageBoxIcon icon)

Sometimes the MessageBox would successfully pop up, but then clicking
somewhere on the messagebox would cause a similar
NullReferenceException! After running these apps a LOT, we eventually
got the machine in a state where it simply stopped producing the
errors! My only current theory is that he was at some sort of internal
Window Handle limit. It was almost as if he was tottering around that
edge, and by running an app too soon after the previous one, the OS
wouldn't have had a chance to clean up the old window handles...I can't
think of any other reason the timing would have made a difference.

If you do either of these following searches...
SafeNativeMethods.ShowWindow NullReferenceException
SafeNativeMethods.MessageBox NullReferenceException

.... you will see lots of people that are having this problem
intermitently, but there is NO solution out there. It doesn't help
that so few people can repro it! I have seen some MVPs respond, only
to say "Send me a code sample," when always leads to "It works fine on
this end." Frustrating stuff...

If you get to the bottom of this, please let me know what it is! I am
dying to hear. I am quite perplexed by all of this. It definitely
seems machine-state related. Does it help if you reboot at all?

- Taylor (NCsoft)
 
Wow, that's even more complicated than I've seen. Since I just rebooted my
box, I'll give it a try to see if it's still happening.
As we discussed offline, I think it's time to try to get MS support
involved.
- Jeff
 
Back
Top