处理分布式事务超时未回滚的问题需要综合考虑多个因素。首先，您需要确保每个参与的服务都能正确处理事务超时情况。其次，您可以考虑使用一些可靠的分布式事务管理工具，如TCC（Try-Confirm-Cancel）或基于消息的事务处理，来确保跨服务的事务能够正确回滚。

在您的系统中，您可以尝试使用分布式事务调器（DTC）来管理跨的事。这有助于确保如果其中一个服务因超时而未能正确回滚事务，DTC可以协调参与者，以确保事务的一致性。

另选择是使用基于消息的事务处理模式。在这种模式下，您可以使用消息队列来确保各个服务之间事务操作是可的。当某个服务在执行事务时发生超时，可以通过消息列的重试机制来确保事务的回滚操作最终能够成功完成。

除此之外您还可以考虑使用分布式事务管理工具或框架，如Seata、Saga或Atomikos等，它们提供了成熟的分布式事务解决方案，可以帮助您更好地管理跨服务的事务操作。

总的来说，处理分布式务超时未回滚的问题需要综合考虑系统架构、服务间通信机制以及事务管理工具的选择，以确保系统在面对超时情况时能够正确处理并回滚事务。

Sure, here is a basic example of how you would typically use a transaction in .NET Core.

Please note, this example uses Entity Framework Core which supports transactions.

public class SampleService
{
    private readonly MyDbContext _context;

    public SampleService(MyDbContext context)
    {
        _context = context;
    }

    public async Task SampleTransactionAsync()
    {
        using var transaction = await _context.Database.BeginTransactionAsync();
        try
        {
            // Perform your data modifications here

            _context.Entity.Add(new Entity());
            //...

            await _context.SaveChangesAsync();

            await transaction.CommitAsync();
        }
        catch (Exception)
        {
            await transaction.RollbackAsync();
            throw;
        }
    }
}

In this example, the code starts a new transaction using BeginTransactionAsync(). If everything is successful within the try block, it commits the transaction using CommitAsync() and all changes are saved into the database. If an exception is thrown within the `` block, it rolls back the transaction with RollbackAsync(), and no changes are saved into the database.

Remember, this is just a simple example. Real-world scenarios, especially in distributed systems, can be much more complex and might require more advanced techniques and tools than just basic transactions.

Handling distributed transactions, especially when they do not properly rollback due to timeout, can be a bit tricky in a system implemented in .NET Core. Yet, there are several methods to manage such scenarios effectively:

1. Use a library that implements a distributed transaction coordinator. While .NET Core doesn'tatively support the Microsoft Distributed Transaction Coordinator (MSDTC), there are third-party libraries available such as CAP, which is a popular library to solve the problem of distributed transactions based on message queues.

2. Saga pattern. The Saga pattern is a design pattern that sequentially applies a series of local transactions and coordinates them to ensure a consistent outcome. If one local transaction fails, steps are taken to compensate for the changes made by the previous local transactions. In a microservices architecture, this is often implemented as an orchestration service that coordinates the different services involved.

Here is an example of a saga implemented Masstransit, a popular .NET bus library:

public class SubmitOrderSaga :
    MassTransitStateMachine<OrderSagaState>
{
    public SubmitOrderSaga()
    {
        InstanceState(x => x.CurrentState);

        Event(() => OrderSubmitted, x =>
        {
            x.CorrelateById(ctx => ctx.Message.OrderId);
            x.IsRequired();
        });

        Schedule(() => ValidateOrder, x => x.ValidationTokenId, cfg =>
        {
            cfg.Delay = TimeSpan.FromSeconds(10);
            cfg.Received = e =>
                e.CorrelateById(ctx => ctx.Message.OrderId).OnMissingInstance(m => m.Discard());
        });

        Initially(
            When(OrderSubmitted)
                .Schedule(ValidateOrder, context => new ValidateOrder{OrderId = context.Data.OrderId})
                .TransitionTo(Submitted));

        During(Submitted,
            When(OrderSubmitted)
                .Then(context =>
 {
                    // Update the state
                }),
            When(ValidateOrder.Received)
                .Then(context =>
                {
                    // Order was valid
                })
                .TransitionTo(Accepted));
    }

    public State Submitted { get; private set; }
    public State Accepted { get; private set; }

    public Event<OrderSubmitted> OrderSubmitted { get; private set }

    public Schedule<OrderSagaState, ValidateOrder> ValidateOrder { get; private set; }
}

Remember: In a distributed transaction where timeouts occur, these are complex situations that often require bespoke handling based on the specifics of your system. It might not always be as straightforward as wrapping everything in a TransactionScope.