Hello
I am implementing/maintaining a custom Visual Studio engine which uses the (old) AD7 interfaces (so not Concord).
We support heterogeneous debugging of a native Windows process (debugged by the VS debug engine) working together with several remote processes running on different hardware (each debugged by one instances of our debug engine).
In that scenario it happens that we have duplicate process or thread ids debugged in different engines but in one VS debug session.
So for example:
Process 8172 (2 threads) // running on Windows
* 9888 Main Thread
* 7412 Worker Thread 1
Process 6822 (2 threads) // running on remote system 1
* 1 Main Thread
* 2 Worker Thread 1
Process 6800 (2 threads) // running on remote system 2
* 1 Main Thread
* 2 Worker Thread 1
So here my issue: The VS Thread Window gets confused by these duplicate thread ids!
So this is what it shows in above scenario:
Process 8172 (2 threads) // running on Windows
* 9888 Main Thread
* 7412 Worker Thread 1
Process 6822 (2 threads) // running on remote system 1
*
*
Process 6800 (2 threads) // running on remote system 2
* 1 Main Thread
* 2 Worker Thread 1
(so the first 2 threads are ghost entries - empty lines)
It seems the VS IDE assumes that thread ids (and process ids) are unique, which is valid when debugging on one OS.
But there is no way for me to guarantee that thread ids (or process ids) are actually different/unique when working with several OS'es (running on different hardware).
The interface that gets called to identify a thread is
int IDebugThread2.GetThreadId(out uint threadId)
Unfortunately this interface identifies threads just with a "uint".
And the Windows host system already uses the complete 2^32 range, so i cant just extend my id's to them to make them unique.
Has anyone here an idea how I can work around / solve this issue?
Do Threads really only get identified with that uint id?
How is this solved in VS Remote Debugging, when you could actually debug 2 processes from different remote systems with identical process and thread ids?
The assumption that process and thread ids are unique seems to me wrong for such scenarios...
Regards,
Belkar
I am implementing/maintaining a custom Visual Studio engine which uses the (old) AD7 interfaces (so not Concord).
We support heterogeneous debugging of a native Windows process (debugged by the VS debug engine) working together with several remote processes running on different hardware (each debugged by one instances of our debug engine).
In that scenario it happens that we have duplicate process or thread ids debugged in different engines but in one VS debug session.
So for example:
Process 8172 (2 threads) // running on Windows
* 9888 Main Thread
* 7412 Worker Thread 1
Process 6822 (2 threads) // running on remote system 1
* 1 Main Thread
* 2 Worker Thread 1
Process 6800 (2 threads) // running on remote system 2
* 1 Main Thread
* 2 Worker Thread 1
So here my issue: The VS Thread Window gets confused by these duplicate thread ids!
So this is what it shows in above scenario:
Process 8172 (2 threads) // running on Windows
* 9888 Main Thread
* 7412 Worker Thread 1
Process 6822 (2 threads) // running on remote system 1
*
*
Process 6800 (2 threads) // running on remote system 2
* 1 Main Thread
* 2 Worker Thread 1
(so the first 2 threads are ghost entries - empty lines)
It seems the VS IDE assumes that thread ids (and process ids) are unique, which is valid when debugging on one OS.
But there is no way for me to guarantee that thread ids (or process ids) are actually different/unique when working with several OS'es (running on different hardware).
The interface that gets called to identify a thread is
int IDebugThread2.GetThreadId(out uint threadId)
Unfortunately this interface identifies threads just with a "uint".
And the Windows host system already uses the complete 2^32 range, so i cant just extend my id's to them to make them unique.
Has anyone here an idea how I can work around / solve this issue?
Do Threads really only get identified with that uint id?
How is this solved in VS Remote Debugging, when you could actually debug 2 processes from different remote systems with identical process and thread ids?
The assumption that process and thread ids are unique seems to me wrong for such scenarios...
Regards,
Belkar