Problem loading Visual Studio 6.0 on WinXpe

[hanleyh1]

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.

[Slobodan Brcin (eMVP)]

Hi,

You can use remote debugging trough network from your VS on development computer.

http://groups-beta.google.com/group/microsoft.public.windowsxp.embedded/search?group=microsoft.public.windowsxp.embedded&q=Visual+Studio&qt_g=1

Regards,
Slobodan

"hanleyh1" <hanl...@discussions.microsoft.com> wrote in message news:82D4FC6A-4E7A-47C3...@microsoft.com...

[hanleyh1]

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

[Slobodan Brcin (eMVP)]

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

"hanleyh1" <hanl...@discussions.microsoft.com> wrote in message news:16BA94FB-DF31-40E0...@microsoft.com...

[hanleyh1]

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

[Slobodan Brcin (eMVP)]

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

"hanleyh1" <hanl...@discussions.microsoft.com> wrote in message news:91E9D2BA-CFB6-4AA6...@microsoft.com...

[hanleyh1]

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.

[Slobodan Brcin (eMVP)]

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?

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?

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

[KM]

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?

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?

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.

--
Regards,
KM, BSquare Corp.