c0000029

VFP8. This is a new one on me. This line of code causes this error:

TRY
IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar

glVar is undefined, and instead of jumping to the CATCH statement like it
should, it crashes with c0000029.

Dan
Fri Jan 07 11:45:45 CST 2005

Odd. I get

Function name is missing ).

Dan

Ook wrote:
> VFP8. This is a new one on me. This line of code causes this error:
>
> TRY
> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
>
> glVar is undefined, and instead of jumping to the CATCH statement
> like it should, it crashes with c0000029.

Ook
Fri Jan 07 12:08:45 CST 2005

That is because I mistyped it.

UPPER(SUBSTR(JUSTSTEM(DBF()),4,4))

What it will normally do is give you a messge, Variable GLVAR is not found.
In this particular case, it generates a c0000029.




"Dan Freeman" <spam@microsoft.com> wrote in message
news:OQKX4CO9EHA.2112@TK2MSFTNGP14.phx.gbl...
> Odd. I get
>
> Function name is missing ).
>
> Dan
>
> Ook wrote:
> > VFP8. This is a new one on me. This line of code causes this error:
> >
> > TRY
> > IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
> >
> > glVar is undefined, and instead of jumping to the CATCH statement
> > like it should, it crashes with c0000029.
>
>

Dan
Fri Jan 07 13:35:36 CST 2005

Does it do it for you in a standalone prg?

If not, then odds are that's NOT where the error is. It just happens to be
where it was reported to you.

Dan

Ook wrote:
> That is because I mistyped it.
>
> UPPER(SUBSTR(JUSTSTEM(DBF()),4,4))
>
> What it will normally do is give you a messge, Variable GLVAR is not
> found. In this particular case, it generates a c0000029.
>
>
>
>
> "Dan Freeman" <spam@microsoft.com> wrote in message
> news:OQKX4CO9EHA.2112@TK2MSFTNGP14.phx.gbl...
>> Odd. I get
>>
>> Function name is missing ).
>>
>> Dan
>>
>> Ook wrote:
>>> VFP8. This is a new one on me. This line of code causes this error:
>>>
>>> TRY
>>> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
>>>
>>> glVar is undefined, and instead of jumping to the CATCH statement
>>> like it should, it crashes with c0000029.

Rick
Fri Jan 07 13:43:05 CST 2005

Ook,
So far the only reference I can find to C0000029 is =
http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;250886 - =
"MicroStation Version 5.0 Closes When You Try to Print from Windows =
2000-Based Computer".

Just found another in a DDK header file ():
//
// MessageId: STATUS_INVALID_UNWIND_TARGET
//
// MessageText:
//
// An invalid unwind target was encountered during an unwind operation.
//
#define STATUS_INVALID_UNWIND_TARGET ((NTSTATUS)0xC0000029L)
//

I haven't a clue what an unwind operation is!

Rick

"Ook" <usenet@nospam.emberts.com> wrote in message =
news:ekh1ATN9EHA.2608@TK2MSFTNGP10.phx.gbl...
> VFP8. This is a new one on me. This line of code causes this error:
>=20
> TRY
> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
>=20
> glVar is undefined, and instead of jumping to the CATCH statement like =
it
> should, it crashes with c0000029.
>=20
>

Ook
Fri Jan 07 14:29:57 CST 2005

I saw that - it was less then helpfull. I gather this is not a common error.
At first I thought it was just the normal c0000005, but then I noticed it
was something different. It is 100% duplicatable in my environment, which
includes a massive code base. I'm not sure if I can create a simple app to
duplicate this.

"Rick Bean" <rgbean@unrealmelange-inc.com> wrote in message
news:ufaOeEP9EHA.2608@TK2MSFTNGP10.phx.gbl...
Ook,
So far the only reference I can find to C0000029 is
http://support.microsoft.com/default.aspx?scid=kb;en-us;250886 -
"MicroStation Version 5.0 Closes When You Try to Print from Windows
2000-Based Computer".

Just found another in a DDK header file ():
//
// MessageId: STATUS_INVALID_UNWIND_TARGET
//
// MessageText:
//
// An invalid unwind target was encountered during an unwind operation.
//
#define STATUS_INVALID_UNWIND_TARGET ((NTSTATUS)0xC0000029L)
//

I haven't a clue what an unwind operation is!

Rick

"Ook" <usenet@nospam.emberts.com> wrote in message
news:ekh1ATN9EHA.2608@TK2MSFTNGP10.phx.gbl...
> VFP8. This is a new one on me. This line of code causes this error:
>
> TRY
> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
>
> glVar is undefined, and instead of jumping to the CATCH statement like it
> should, it crashes with c0000029.
>
>

Ook
Fri Jan 07 14:31:26 CST 2005

If I step through the code, that is where it crashes. Of course it works
fine in a standalone PRG. I really don't know where or how VFP is getting
confused, but it's likely that the specific and unique environment that
exists at the time is causing it to crash exactly where I'm seeing it crash.
This, or course, makes it very difficult to troubleshoot.


"Dan Freeman" <spam@microsoft.com> wrote in message
news:OrYERAP9EHA.1084@TK2MSFTNGP15.phx.gbl...
> Does it do it for you in a standalone prg?
>
> If not, then odds are that's NOT where the error is. It just happens to be
> where it was reported to you.
>
> Dan
>
> Ook wrote:
> > That is because I mistyped it.
> >
> > UPPER(SUBSTR(JUSTSTEM(DBF()),4,4))
> >
> > What it will normally do is give you a messge, Variable GLVAR is not
> > found. In this particular case, it generates a c0000029.
> >
> >
> >
> >
> > "Dan Freeman" <spam@microsoft.com> wrote in message
> > news:OQKX4CO9EHA.2112@TK2MSFTNGP14.phx.gbl...
> >> Odd. I get
> >>
> >> Function name is missing ).
> >>
> >> Dan
> >>
> >> Ook wrote:
> >>> VFP8. This is a new one on me. This line of code causes this error:
> >>>
> >>> TRY
> >>> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
> >>>
> >>> glVar is undefined, and instead of jumping to the CATCH statement
> >>> like it should, it crashes with c0000029.
>
>

Dan
Fri Jan 07 15:24:58 CST 2005

The debugger has been known to cause "unpredictable" behavior. I trust with
each crash you're choosing the option to "Send to Microsoft"? They actually
use those things and have fixed a number of product bugs using the
information in them.

Dan

Ook wrote:
> If I step through the code, that is where it crashes. Of course it
> works fine in a standalone PRG. I really don't know where or how VFP
> is getting confused, but it's likely that the specific and unique
> environment that exists at the time is causing it to crash exactly
> where I'm seeing it crash. This, or course, makes it very difficult
> to troubleshoot.
>
>
> "Dan Freeman" <spam@microsoft.com> wrote in message
> news:OrYERAP9EHA.1084@TK2MSFTNGP15.phx.gbl...
>> Does it do it for you in a standalone prg?
>>
>> If not, then odds are that's NOT where the error is. It just happens
>> to be where it was reported to you.
>>
>> Dan
>>
>> Ook wrote:
>>> That is because I mistyped it.
>>>
>>> UPPER(SUBSTR(JUSTSTEM(DBF()),4,4))
>>>
>>> What it will normally do is give you a messge, Variable GLVAR is not
>>> found. In this particular case, it generates a c0000029.
>>>
>>>
>>>
>>>
>>> "Dan Freeman" <spam@microsoft.com> wrote in message
>>> news:OQKX4CO9EHA.2112@TK2MSFTNGP14.phx.gbl...
>>>> Odd. I get
>>>>
>>>> Function name is missing ).
>>>>
>>>> Dan
>>>>
>>>> Ook wrote:
>>>>> VFP8. This is a new one on me. This line of code causes this
>>>>> error:
>>>>>
>>>>> TRY
>>>>> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
>>>>>
>>>>> glVar is undefined, and instead of jumping to the CATCH statement
>>>>> like it should, it crashes with c0000029.

Ook
Fri Jan 07 17:07:20 CST 2005

Debugger crashes and hangs are old news. This occurs when running the EXE in
a production environment, and the error log also points to the same line of
code the it crashes at when stepping through the program so I'm not certain
the debugger has anything to do with this. MS actually uses those things? My
paranoid self wonders if it just sends a list of all mp3s on my computer or
something like that LOL....


"Dan Freeman" <spam@microsoft.com> wrote in message
news:eCuJY9P9EHA.1228@tk2msftngp13.phx.gbl...
> The debugger has been known to cause "unpredictable" behavior. I trust
with
> each crash you're choosing the option to "Send to Microsoft"? They
actually
> use those things and have fixed a number of product bugs using the
> information in them.
>
> Dan
>
> Ook wrote:
> > If I step through the code, that is where it crashes. Of course it
> > works fine in a standalone PRG. I really don't know where or how VFP
> > is getting confused, but it's likely that the specific and unique
> > environment that exists at the time is causing it to crash exactly
> > where I'm seeing it crash. This, or course, makes it very difficult
> > to troubleshoot.
> >
> >
> > "Dan Freeman" <spam@microsoft.com> wrote in message
> > news:OrYERAP9EHA.1084@TK2MSFTNGP15.phx.gbl...
> >> Does it do it for you in a standalone prg?
> >>
> >> If not, then odds are that's NOT where the error is. It just happens
> >> to be where it was reported to you.
> >>
> >> Dan
> >>
> >> Ook wrote:
> >>> That is because I mistyped it.
> >>>
> >>> UPPER(SUBSTR(JUSTSTEM(DBF()),4,4))
> >>>
> >>> What it will normally do is give you a messge, Variable GLVAR is not
> >>> found. In this particular case, it generates a c0000029.
> >>>
> >>>
> >>>
> >>>
> >>> "Dan Freeman" <spam@microsoft.com> wrote in message
> >>> news:OQKX4CO9EHA.2112@TK2MSFTNGP14.phx.gbl...
> >>>> Odd. I get
> >>>>
> >>>> Function name is missing ).
> >>>>
> >>>> Dan
> >>>>
> >>>> Ook wrote:
> >>>>> VFP8. This is a new one on me. This line of code causes this
> >>>>> error:
> >>>>>
> >>>>> TRY
> >>>>> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
> >>>>>
> >>>>> glVar is undefined, and instead of jumping to the CATCH statement
> >>>>> like it should, it crashes with c0000029.
>
>

Ook
Fri Jan 07 18:58:10 CST 2005

Interesting enough, I just now discovered that one of the fields being
replaced that triggers this code had an invalid name in it. I fixed the
field name and the crash doesn't happen, even though the line of code that
the crash occurs on didn't have anything to do with the crash. Somehow,
doing a replace on an invalid field name was ultimately triggering this
crash. Weird.

Also of interest, I just discovered that if you have an ON ERROR condition
in effect, then the TRY/CATCH never triggers, as it appears that the ON
ERROR supercedes the TRY/CATCH (at least it is in this particular
instance.). I took a quick glance at the docs, and they seem to indicate
that the TRY/CATCH takes precedence. <shrug>

"Dan Freeman" <spam@microsoft.com> wrote in message
news:eCuJY9P9EHA.1228@tk2msftngp13.phx.gbl...
> The debugger has been known to cause "unpredictable" behavior. I trust
with
> each crash you're choosing the option to "Send to Microsoft"? They
actually
> use those things and have fixed a number of product bugs using the
> information in them.
>
> Dan
>
> Ook wrote:
> > If I step through the code, that is where it crashes. Of course it
> > works fine in a standalone PRG. I really don't know where or how VFP
> > is getting confused, but it's likely that the specific and unique
> > environment that exists at the time is causing it to crash exactly
> > where I'm seeing it crash. This, or course, makes it very difficult
> > to troubleshoot.
> >
> >
> > "Dan Freeman" <spam@microsoft.com> wrote in message
> > news:OrYERAP9EHA.1084@TK2MSFTNGP15.phx.gbl...
> >> Does it do it for you in a standalone prg?
> >>
> >> If not, then odds are that's NOT where the error is. It just happens
> >> to be where it was reported to you.
> >>
> >> Dan
> >>
> >> Ook wrote:
> >>> That is because I mistyped it.
> >>>
> >>> UPPER(SUBSTR(JUSTSTEM(DBF()),4,4))
> >>>
> >>> What it will normally do is give you a messge, Variable GLVAR is not
> >>> found. In this particular case, it generates a c0000029.
> >>>
> >>>
> >>>
> >>>
> >>> "Dan Freeman" <spam@microsoft.com> wrote in message
> >>> news:OQKX4CO9EHA.2112@TK2MSFTNGP14.phx.gbl...
> >>>> Odd. I get
> >>>>
> >>>> Function name is missing ).
> >>>>
> >>>> Dan
> >>>>
> >>>> Ook wrote:
> >>>>> VFP8. This is a new one on me. This line of code causes this
> >>>>> error:
> >>>>>
> >>>>> TRY
> >>>>> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
> >>>>>
> >>>>> glVar is undefined, and instead of jumping to the CATCH statement
> >>>>> like it should, it crashes with c0000029.
>
>

Dan
Mon Jan 10 12:21:09 CST 2005

Like I said two messages back, the error had nothing to do with the line of
code being reported.

Try/Catch definitely takes precedence .... except when things are so
wopperjogged in memory Fox is about to die and then all bets are off as to
what's going to happen, what you'll see, and what is reported.

Dan

Ook wrote:
> Interesting enough, I just now discovered that one of the fields being
> replaced that triggers this code had an invalid name in it. I fixed
> the field name and the crash doesn't happen, even though the line of
> code that the crash occurs on didn't have anything to do with the
> crash. Somehow, doing a replace on an invalid field name was
> ultimately triggering this crash. Weird.
>
> Also of interest, I just discovered that if you have an ON ERROR
> condition in effect, then the TRY/CATCH never triggers, as it appears
> that the ON ERROR supercedes the TRY/CATCH (at least it is in this
> particular instance.). I took a quick glance at the docs, and they
> seem to indicate that the TRY/CATCH takes precedence. <shrug>
>
> "Dan Freeman" <spam@microsoft.com> wrote in message
> news:eCuJY9P9EHA.1228@tk2msftngp13.phx.gbl...
>> The debugger has been known to cause "unpredictable" behavior. I
>> trust with each crash you're choosing the option to "Send to
>> Microsoft"? They actually use those things and have fixed a number
>> of product bugs using the information in them.
>>
>> Dan
>>
>> Ook wrote:
>>> If I step through the code, that is where it crashes. Of course it
>>> works fine in a standalone PRG. I really don't know where or how VFP
>>> is getting confused, but it's likely that the specific and unique
>>> environment that exists at the time is causing it to crash exactly
>>> where I'm seeing it crash. This, or course, makes it very difficult
>>> to troubleshoot.
>>>
>>>
>>> "Dan Freeman" <spam@microsoft.com> wrote in message
>>> news:OrYERAP9EHA.1084@TK2MSFTNGP15.phx.gbl...
>>>> Does it do it for you in a standalone prg?
>>>>
>>>> If not, then odds are that's NOT where the error is. It just
>>>> happens to be where it was reported to you.
>>>>
>>>> Dan
>>>>
>>>> Ook wrote:
>>>>> That is because I mistyped it.
>>>>>
>>>>> UPPER(SUBSTR(JUSTSTEM(DBF()),4,4))
>>>>>
>>>>> What it will normally do is give you a messge, Variable GLVAR is
>>>>> not found. In this particular case, it generates a c0000029.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Dan Freeman" <spam@microsoft.com> wrote in message
>>>>> news:OQKX4CO9EHA.2112@TK2MSFTNGP14.phx.gbl...
>>>>>> Odd. I get
>>>>>>
>>>>>> Function name is missing ).
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> Ook wrote:
>>>>>>> VFP8. This is a new one on me. This line of code causes this
>>>>>>> error:
>>>>>>>
>>>>>>> TRY
>>>>>>> IF (UPPER(SUBSTR(JUSTSTEM(DBF()),4,4) <> 'ZOOT' .AND. glVar
>>>>>>>
>>>>>>> glVar is undefined, and instead of jumping to the CATCH
>>>>>>> statement like it should, it crashes with c0000029.

Ook
Mon Jan 10 15:17:47 CST 2005

I have sucessfully duplicated the c0000029 crash. This appears to be a ...
um ... feature by design ... in VFP8. Here is how you do it:

Create a DBC. Create two tables with identical structure. Put some data in
them. One of the fields should be CHANGE, type = DateTime. Create a
procedure in the DBC called SETCHANGE (or whatever you want to call it). Put
this code in the procedure:

PROCEDURE setChange
TRY
IF glSetChange
REPLACE CHANGE WITH DATETIME()
ENDIF
CATCH
WAIT WINDOW 'An error has occured'
ENDTRY
RETURN .T.
ENDPROC


In one of your tables, set the record validation Rule: to setchange(), I did
it in the table ZOOT.

Then, create a prg with this code
USE ZOOT1
SELECT 0
USE ZOOT
REPLACE AA WITH zoot1.aa, a1 WITH zoot1.aaa

The second WITH... must be invalid, IE there must be an error in the
table/field name. The first WITH must be valid. Note that zoot1.aa is valid,
zoot1.aaa does not exist because there is no field aaa. If you meet these
conditions, you should get the c0000029 error at IF glSetChange. Note that
glSetChange must be unitialized, which would normally trigger an error
instead of crashing.

This was causing our app to crash because someone had put in an invalid
field name, probably a typo, and under certain circumstances glSetChange is
indeed uninitialized, hence the TRY/CATCH block.

Screen shots:
http://zootal.no-ip.info/stuff/c0000029.jpg

And, you guys gotta check this out!!!
http://zootal.no-ip.info/stuff/c0000029a.jpg

If I had the time, I could probably set this up so that executing my program
takes control of your computer, resets you DVC player, turns on your
microwave oven, etc.....

And, finally, not quite as exciting:
http://zootal.no-ip.info/stuff/c0000029b.jpg



If anyone reads this far and has trouble duplicating this, I can post a
sample program on my website to demonstrate the crash.

Ook
Mon Jan 10 15:24:22 CST 2005

Disclaimer. The code I posted actually generates the mismatched mismatched
pushjmp/popjmp call error. Variations on the code generate the buffer
overrun or c0000029. In either case it appears that VFP is getting borked.


"Ook" <usenet@nospam.emberts.com> wrote in message
news:%238GvXn19EHA.3616@TK2MSFTNGP11.phx.gbl...
> I have sucessfully duplicated the c0000029 crash. This appears to be a ...
> um ... feature by design ... in VFP8. Here is how you do it:
>
> Create a DBC. Create two tables with identical structure. Put some data in
> them. One of the fields should be CHANGE, type = DateTime. Create a
> procedure in the DBC called SETCHANGE (or whatever you want to call it).
Put
> this code in the procedure:
>
> PROCEDURE setChange
> TRY
> IF glSetChange
> REPLACE CHANGE WITH DATETIME()
> ENDIF
> CATCH
> WAIT WINDOW 'An error has occured'
> ENDTRY
> RETURN .T.
> ENDPROC
>
>
> In one of your tables, set the record validation Rule: to setchange(), I
did
> it in the table ZOOT.
>
> Then, create a prg with this code
> USE ZOOT1
> SELECT 0
> USE ZOOT
> REPLACE AA WITH zoot1.aa, a1 WITH zoot1.aaa
>
> The second WITH... must be invalid, IE there must be an error in the
> table/field name. The first WITH must be valid. Note that zoot1.aa is
valid,
> zoot1.aaa does not exist because there is no field aaa. If you meet these
> conditions, you should get the c0000029 error at IF glSetChange. Note
that
> glSetChange must be unitialized, which would normally trigger an error
> instead of crashing.
>
> This was causing our app to crash because someone had put in an invalid
> field name, probably a typo, and under certain circumstances glSetChange
is
> indeed uninitialized, hence the TRY/CATCH block.
>
> Screen shots:
> http://zootal.no-ip.info/stuff/c0000029.jpg
>
> And, you guys gotta check this out!!!
> http://zootal.no-ip.info/stuff/c0000029a.jpg
>
> If I had the time, I could probably set this up so that executing my
program
> takes control of your computer, resets you DVC player, turns on your
> microwave oven, etc.....
>
> And, finally, not quite as exciting:
> http://zootal.no-ip.info/stuff/c0000029b.jpg
>
>
>
> If anyone reads this far and has trouble duplicating this, I can post a
> sample program on my website to demonstrate the crash.
>
>