Problem loading Visual Studio 6.0 on WinXpe

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We are developing a product using Visual Studio 6.0, intended to run on
WinXpe. Thusfar we have done our development on WinXp and then moved the
executable to the single board computer (SBC) running WinXpe. Recently we
have found we need to debug the program on the SBC and so I tried to install
Visual Studio 6.0 onto the SBC. I got an error "The instruction at
0x77f8d85d referenced memory at 0x0000000053. The memory could not be read."
I have emailed to the vendor of our SBC, but was wondering if others have
had success/problems putting Visual Studio 6.0 onto WinXpe.
 
I have tried to use the remote debugging, but my executable crashes because
it is trying to do some port I/O. I am guessing that the host computer's
debugger somehow figures out that it can't read a port on another computer.
Is this one of the weak spots of remote debugging, or should I be able to
remotely debug an application that does a lot of I/O?

-hanley
 
You should be able to do remote debugging in all cases.
What do you use for your network connection?
I hope that you use network and not serial adapter.

Regards,
Slobodan
 
We are using network connection. Are you saying that the debugger should be
able to handle I/O from the target machine?

-hanley
 
Hi,

I'm saying that I had never had problem with debugging and I have a huge amount of hardware IO operations. (From driver of course)
How do you do IO operations?

Regards,
Slobodan
 
Sorry, I was mistaken. I was missing a .dll related to the i/o operation.
Once I put the .dll in /windows/system32 I was able to remotely debug. Since
it appears you do a lot of remote debugging, maybe you could answer the
following questions for me.

1. The dlls on my host and target computers are different (sizes/dates),
which doesn't appear to be a problem other than when I first start the
debugger, it pops up a dialog that has to be clicked on for each of these
dlls that differ. Is there anyway to avoid this?

2. I'd love to be able to debug from my computer (the host), 50 feet away
from the target (testbed) system, but the application's GUI comes up on the
target system that require mouseclicks and keypresses to navigate through
menus and dialogs. Is there a way to get the debugger and the display to
come up on the host system, so that basically, I am just using the hardware
on the target system?

Thanks for all your help.

-hanley
 
Hi Hanley,
Sorry, I was mistaken. I was missing a .dll related to the i/o operation.
Once I put the .dll in /windows/system32 I was able to remotely debug. Since
it appears you do a lot of remote debugging, maybe you could answer the
following questions for me.

1. The dlls on my host and target computers are different (sizes/dates),
which doesn't appear to be a problem other than when I first start the
debugger, it pops up a dialog that has to be clicked on for each of these
dlls that differ. Is there anyway to avoid this?
Click to expand...

Strange, I can't recall this problem if I ever had it. I just wonder if this could be related to missing symbols problem.
2. I'd love to be able to debug from my computer (the host), 50 feet away
from the target (testbed) system, but the application's GUI comes up on the
target system that require mouseclicks and keypresses to navigate through
menus and dialogs. Is there a way to get the debugger and the display to
come up on the host system, so that basically, I am just using the hardware
on the target system?
Click to expand...

Huh I must admit that all my test devices are placed around me so I have never needed this option.
But you can try RDP (Remote Desktop Protocol). Unfortunately this will require XPe image modification to support this and it might
distort the real product features that will be present at the end.

Regards,
Slobodan
 
hanley,
Sorry, I was mistaken. I was missing a .dll related to the i/o operation.
Once I put the .dll in /windows/system32 I was able to remotely debug. Since
it appears you do a lot of remote debugging, maybe you could answer the
following questions for me.

1. The dlls on my host and target computers are different (sizes/dates),
which doesn't appear to be a problem other than when I first start the
debugger, it pops up a dialog that has to be clicked on for each of these
dlls that differ. Is there anyway to avoid this?
Click to expand...

You can make finding the DLLs easier. Have the same path on Local and Remote machine (could be a mapped driver, share or anything
you prefer) and put all the target Dlls, Pdbs there. In the VC set the remote path option to that path (share).
2. I'd love to be able to debug from my computer (the host), 50 feet away
from the target (testbed) system, but the application's GUI comes up on the
target system that require mouseclicks and keypresses to navigate through
menus and dialogs. Is there a way to get the debugger and the display to
come up on the host system, so that basically, I am just using the hardware
on the target system?
Click to expand...

How about using a 3rd party tools to remotely control the target?
Like VNC or RAdmin (lightweight). RDP may also work but I never tried it with Remote Debugging. Also, RDP stack of components to
include is pretty big.
 
Back
Top