Very strange "input string not in correct format" bug

[Jen]

One user of my application is experiencing an exception "input string not in
correct format". But it makes no sense where it is occurring. It is
occurring when a string from a textbox ("172") is being convert to an Int16
(using Convert.ToInt16). How can that be? There are other text boxes that
are used in the identical fashion and they don't generate the exception.
All there are many other machines running my application that don't generate
the exception at all.

I have no idea what the problem could be and am looking for ideas.

 

[Jon Skeet [C# MVP]]

One user of my application is experiencing an exception "input string not in
correct format". But it makes no sense where it is occurring. It is
occurring when a string from a textbox ("172") is being convert to an Int16
(using Convert.ToInt16). How can that be? There are other text boxes that
are used in the identical fashion and they don't generate the exception.
All there are many other machines running my application that don't generate
the exception at all.

I have no idea what the problem could be and am looking for ideas.

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

 

[Jen]

I can post the relevant code snippets but I doubt I can reproduce the
problem. It's only occuring on one machine out of about a dozen tested.

 

[Jon Skeet [C# MVP]]

I can post the relevant code snippets but I doubt I can reproduce the
problem. It's only occuring on one machine out of about a dozen tested.

Can you produce a short but complete program that fails on that single
machine? (A console app would be easiest.)

It does sound very odd...

 

[Jen]

I'll see what I can do.

This almost smells like a culture-conversion type of problem. But
converting a string that only contains an integer number (and a small
integer number at that) to an int16? How can that fail? But I've been
Googling and it appears others have experienced it as well. Not sure about
an easy fix yet though.

 

[mpetrotta]

I can post the relevant code snippets but I doubt I can reproduce the
problem. It's only occuring on one machine out of about a dozen tested.

This sounds similar to a problem I saw a few months ago:

"Convert.ToInt32("0") throws an exception, some systems"
http://groups.google.com/group/micr..._frm/thread/1e2a5a340425a67b/9eb8e300c7c60821

I filed a bug with Microsoft; they're not able to reproduce it. You
might want to post some details in that bug report:

https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=253265&wa=wsignin1.0&siteid=210

Michael

 

[Jen]

Yep, it sounds just like my problem. I'm using .NET 2.0 as well.

 

[bob]

Hi Jen,
This is based on nothing but intuition and witchcraft.
Can you check the culture info of the thread just prior to the offending
instruction?
regards
Bob

 

[Laura T.]

What diffrences have the machines that generate exception?
Framework version, hot fixes, OS fixes, UI language/culture etc.?
I tried to reproduce the exception by setting the thread culture to all
possibile cultures I have (158) but did not get any exception from
Convert.ToInt16("172").
The only thing I cannot test that could have something to do with cultures
are the UI cultures but, I'd rather check first what are the differences.

 

[Jen]

I can't really do a detailed analysis of the differences because the
offending machine is not accessible to me at the moment.

What the code is doing is it's taking a string from a TextBox that is part
of a User Control and converting it to a short. The exception's trace looks
something like this:

System.Number.StringToNumber()
System.Number.ParseInt32()
System.Number.Int16.Parse()
Util.IPAddressBox.get_Octet3() <-- this is an Int16 property in my user
control

I'm not sure why the call to ParseInt32 is there but I guess that's the way
it works. I've also seen the exception happen with textboxes that convert
right to Int32 instead of Int16. They are also accessed through a property
of a user control.


I am having the guy that owns the machine try the "set locale to something
else then back again to English (US)" trick that someone mentioned to see if
that fixes it. If it does not I'll pursue additional debugging.

 

[Jen]

It is very strange, that's for sure. Like in the example trace I posted
notice it was the 3rd octet of the IP address that threw the exception.
There were two octets before that that worked fine! Of course the numbers
in the textboxes are all different but all of them had valid small integers.

 

[Jen]

Well, the trick of changing locale to something else and then back again did
fix the problem. I hope Microsoft can eventually find and fix this! It
will be interesting to see how many users of our app. have this problem once
the app. is released. At least we have an easy "fix" now to tell them.

 

[mpetrotta]

Well, the trick of changing locale to something else and then back again did
fix the problem. I hope Microsoft can eventually find and fix this! It
will be interesting to see how many users of our app. have this problem once
the app. is released. At least we have an easy "fix" now to tell them.

FWIW, I have another machine exhibiting this problem, and I've been
emailing back and forth with the class library team about it. They're
trying to debug it when neither I nor MS has physical access to the
machine. Not easy.

Michael

 

[mpetrotta]

FWIW, I have another machine exhibiting this problem, and I've been
emailing back and forth with the class library team about it. They're
trying to debug it when neither I nor MS has physical access to the
machine. Not easy.

For reference, here's what we found. The affected machine had bad
data for the registry value [HKEY_CURRENT_USER\Control Panel
\International\sPositiveSign]. Normally, this value is an empty
REG_SZ (null-terminated string). In this case, the string was missing
its terminator. This confused the API function GetLocaleInfoW(),
causing it to think that '0' (ASCII number zero) was the positive sign
for the current locale (it should normally be '+'). This caused all
kinds of havoc.

You can verify this for yourself with regedit.exe: open that reg value
by right-clicking on the value and selecting 'Modify Binary Data'.
You should see two dots on the right (representing the null
terminator). If you see no dots, you're affected. Fix it by adding a
terminator (four zeros).

You can also check the value of
CultureInfo.CurrentCulture.NumberFormat.PositiveSign; it should be
'+'.

It's a bug in the Windows localization API, not the class libs. The
reg value needs to be checked for a terminator. They're looking at it.

Michael