Help debugging Fotowire

Antti Mäkelä zarhan at
Sun Jan 16 07:50:24 CST 2005

On Sunday 16 January 2005 14:58, Mike Hearn wrote:

> On Sat, 15 Jan 2005 22:35:04 +0200, Antti Mäkelä wrote:
>> 0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd64b4 L"Lab
>> 0009:Call user32.LoadStringA(67f00000,00000088,7796c3d0,00000100)
>> ret=67f8cfd5
> This is where the error occurs ... it's loading the error message from the
> resource file. So you can ignore the rest of this section.
> Unfortunately that trace doesn't reveal very much. One thing I do notice
> is that the string being converted isn't valid XML. It seems to have been

  The entire exchange, as seen by ethereal is (Follow TCP stream-option):

GET /fworder/fwver.asp?LID=1100&OEM=1100&UPID=1100&VER=
Accept: text/* 
User-Agent: fwPrint 
HTTP/1.1 200 OK 
Connection: close 
Date: Sun, 16 Jan 2005 13:21:56 GMT 
Server: Microsoft-IIS/6.0 
X-Powered-By: ASP.NET 
X-AspNet-Version: 1.1.4322 
Cache-Control: no-cache 
Pragma: no-cache 
Expires: -1 
Content-Type: text/xml; charset=utf-8 
Content-Length: 416 
<?xml version="1.0"?> 
<update><validity>2005/1/21</validity><package><title>Lab Logo

> chopped off a bit. So the question is, where does this string come from?
> If it's a wininet thing then it may be that we're not downloading the
> remote page correctly. Does native wininet help?

With native wininet.dll (again, from win2k SP4) when the connection
initiates, I get an exception and it drops top winedbg.

bash-2.05b$ wine fwPrint
fixme:ole:StdMarshalImpl_MarshalInterface table marshalling unimplemented
wine: Unhandled exception (thread 0013), starting debugger...
WineDbg starting on pid 0xf
Unhandled exception: page fault on read access to 0x00000002 in 32-bit code
In 32 bit mode.
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
 EIP:77ddea9b ESP:7c65e970 EBP:00000000 EFLAGS:00010202(   - 00      - -RI1)
 EAX:00000002 EBX:7c65eaa0 ECX:0000005c EDX:00000000
 ESI:77ccfc80 EDI:00000000
Stack dump:
0x7c65e970:  00000030 7c65e984 77ddea6c 77ddea50
0x7c65e980:  00000000 77213a63 6f646e69 74217377
0x7c65e990:  6f706d65 79726172 746e6920 656e7265
0x7c65e9a0:  69662074 2173656c 746e6f63 2e746e65
0x7c65e9b0:  21356569 0000c000 00000000 00000000
0x7c65e9c0:  00000000 00000000 00000000 77efd488
=>1 0x77ddea9b (0x00000000)
0x77ddea9b: adcb        0x0(%eax),%al

  Anyway, regarding the validity of XML, the first reference to the entire
response from the server is following:

0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd62de
L"1.0\"?>\r\n<update><validity>2005/1/21</validity><package><title>Lab Logo

Next WideCharToMultiByte call is

0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd62f0
L"update><validity>2005/1/21</validity><package><title>Lab Logo
hod>2</method><type>2</type></package><package><title>Lab Logo

 And so it goes, always stripping the first tag away. The full XML string is
not shown in the log entries (I think, note the ...). When the tags from
the beginning are stripped away, more stuff from the end shows up in the
log. A few lines later there is

0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd63e6
age><title>Lab Logo

  that does show the contents all the way to the end (the </update> tag).

Final call is


  At this point it seems that the information is parsed from XML Tags. 

  After this is done comes the parts in the log I note in my earlier message 
(the second snippet, with oleaut32.VarDateFromStr call). 

  What seems to be happening (to me) is that this program is a bit dirty: In
effect the parsing process just finds the next '<' in a string, takes the
tag, finds next >, and store the entire rest of the string beginning from
the next char and does not even bother to cut it off.

  This could explain why the next call is as follows:

0009:Call kernel32.WideCharToMultiByte(00000000,00000000,7ddd6312
L"2005/1/21</validity><package><title>Lab Logo
pe>2</type></package><package><title>Lab Logo

  In effect, now we're trying to process the date information (2005/1/21).
The variable (or whatever) that supposedly contains the information also
has the entire rest of the original XML string.

0009:Ret  kernel32.WideCharToMultiByte() retval=00000009 ret=67f852e8

  This is the return value, I'm assuming that the original call specified
either the delimiter or something so only the first 9 characters are

And so we get to the date:
0009:Call oleaut32.VarDateFromStr(7796c4a0
L"2005/1/21",00000409,00000002,7796ca20) ret=67f596c9

  Also the first call you quoted is part of the process doing this too - the
program at that point is only interested in the string "Lab Logo 2", the
rest of the stuff can just go away..

>> The stuff about GetLocaleInfoW is a bit more interesting. Maybe the date
>> format is locale-specific and Wine implementation cannot parse it?
> There may be a problem here ... some test cases may reveal the issue.

  I'm thinking that the XML parsing is probably not the problem (see above),
so I would like to pursue this approach. What tests cases could I try out?

- Antti Mäkelä - -
There is a theory which states that if ever anyone discovers exactly
what the Universe is for and why it is here,it will instantly disappear
and be replaced by something even more bizarre and inexplicable.

More information about the wine-devel mailing list