Program hangs - I'm so lost

  • Thread starter Thread starter Michael McHenry
  • Start date Start date
M

Michael McHenry

I worked on a program on my Dell laptop. A year ago it was working
fine. Over the last year, I worked on it on primarily on my
thinkpad. The thinkpad is gone and I tried to continue work on the
Dell, but the program locks up in an inexplicable way.

I reverted to the version that was working a year ago and it is also
locking up.

When the program initializes, it fills some arrays of structs with
some data. The program locks up on the same array, row, and column,
and line of code every time. If I make small inconsequential changes
to the program, it locks up on a different array, row, column, and
line of code. The actual instruction it locks up on seems arbitrary.

If I trace through the disassembly, oddly enough, the instruction it
hangs on is a NOP.

When it locks up, the program uses 100% of one core, and doesn't seem
to be doing anything. The VS IDE is not able to break into the
debugger and the UI locks up if you try to.

There is some unsafe code in the program, but if I comment it out, the
problem is still there, but it locks up on a later array. (there are
6 large 65x65 arrays that are being filled.) It is almost as if there
are a fixed number of instructions that will execute and removing
lines from the code means it locks up later.

I have no idea where to go with this.

Please, if anyone has any idea what to do, let me know.

-Michael McHenry
 
Michael said:
I worked on a program on my Dell laptop. A year ago it was working
fine. Over the last year, I worked on it on primarily on my
thinkpad. The thinkpad is gone and I tried to continue work on the
Dell, but the program locks up in an inexplicable way.

I reverted to the version that was working a year ago and it is also
locking up.

When the program initializes, it fills some arrays of structs with
some data. The program locks up on the same array, row, and column,
and line of code every time. If I make small inconsequential changes
to the program, it locks up on a different array, row, column, and
line of code. The actual instruction it locks up on seems arbitrary.

If I trace through the disassembly, oddly enough, the instruction it
hangs on is a NOP.

When it locks up, the program uses 100% of one core, and doesn't seem
to be doing anything. The VS IDE is not able to break into the
debugger and the UI locks up if you try to.

There is some unsafe code in the program, but if I comment it out, the
problem is still there, but it locks up on a later array. (there are
6 large 65x65 arrays that are being filled.) It is almost as if there
are a fixed number of instructions that will execute and removing
lines from the code means it locks up later.

I have no idea where to go with this.

Please, if anyone has any idea what to do, let me know.

-Michael McHenry
Click to expand...

I would try the following, in this order.

1. Clean the project by selecting "Clean Solution" on the "Build" Menu,
then rebuild the application. Sometimes the code doesn't agree with the
executable.

2. Remove, then add again any custom references added to the project.
Maybe something is amiss with a version of a dll referenced.

3. Add your classes individually to a newly created project, then run
that project.
 
1. Clean the project by selecting "Clean Solution" on the "Build" Menu,
then rebuild the application. Sometimes the code doesn't agree with the
executable.

2. Remove, then add again any custom references added to the project.
Maybe something is amiss with a version of a dll referenced.

3. Add your classes individually to a newly created project, then run that
project.
Click to expand...

4. install and use a version control system/code repository.

(and I don't mean this in a flippant or arrogant manner - it's a serious
matter).
 
Doesn't sound like it has to do with the code when even code that worked
before doesn't now.

My guess is a faulty harddrive. if one or more sectors are bad, then the
program code in that place may not be read correctly. Making changes to the
code moves it to another place and some other code ends up in the faulty
place, moving the error to somewhere else in the program.

Could also be memory corruption.

Best regards,
Johnny J.
 
Back
Top