Erro ntdll.dll

[Renato Rubinho]

Tente atualizar as dlls na pasta do exe.

Obs: use a x86, mesmo que seu SO seja x64

https://sourceforge.net/p/acbr/code/HEAD/tree/trunk2/DLLs/LibXml2/x86/

[adromarc]

Em 07/04/2022 at 16:54, adromarc disse:

Depurando o projeto a exceção deu em um método "assinar" nas bibliotecas do ACBr,

Lembrando que quando eu envio na primeira vez a nota vai normal, é na segunda vez que cai nessa exceção.

Deem uma olhada nesta imagem:

 

É no método que está passando o xml que deu a exceçao:

ACBr_DFeComum.ACBrDFeXsLibXml2.TDFeSSLXmlSignLibXml2.Assinar('<?xml version="1.0" encoding="UTF-8"?><NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="4.00" Id="NFe41220407424383000174550010000001881000001898"><ide><cUF>41</cUF><cNF>00000189</cNF><natOp>Venda de mercadoria adquirida ou recebida de terceiros</natOp><mod>55</mod><serie>1</serie><nNF>188</nNF><dhEmi>2022-04-07T00:00:00-03:00</dhEmi><dhSaiEnt>2022-04-07T00:00:00-03:00</dhSaiEnt><tpNF>1</tpNF><idDest>1</idDest><cMunFG>4106605</cMunFG><tpImp>1</tpImp><tpEmis>1</tpEmis><cDV>8</cDV><tpAmb>2</tpAmb><finNFe>1</finNFe><indFinal>1</indFinal><indPres>9</indPres><indIntermed>0</indIntermed><procEmi>0</procEmi><verProc>1.0.0.0</verProc></ide><emit><CNPJ>07424383000174</CNPJ><xNome>POSTO CRUZEIRO COLONIAL LTDA</xNome><xFant>POSTO CRUZEIRO COLONIAL LTDA</xFant><enderEmit><xLgr>AVENIDA SAO PAULO</xLgr><nro>372</nro><xBairro>CENTRO</xBairro><cMun>4106605</cMun><xMun>CRUZEIRO DO OESTE</xMun><UF>PR</UF><CEP>87400000</CEP><cPais>1058</cPais><xPais>BRASIL</xPais><fone>4436762081</fone></enderEmit><IE>9034527900</IE><CRT>3</CRT></emit><dest><CPF>02324142970</CPF><xNome>NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xNome><enderDest><xLgr>RUA JOAO DE RESENDE</xLgr><nro>S/N</nro><xBairro>CENTRO</xBairro><cMun>4106605</cMun><xMun>CRUZEIRO DO OESTE</xMun><UF>PR</UF><CEP>87400000</CEP><cPais>1058</cPais><xPais>BRASIL</xPais></enderDest><indIEDest>9</indIEDest></dest><det nItem="1"><prod><cProd>0030074</cProd><cEAN>SEM GTIN</cEAN><xProd>CHICL. BUBBALOO</xProd><NCM>17041000</NCM><CFOP>5102</CFOP><uCom>UN</uCom><qCom>1.0000</qCom><vUnCom>0.1500000000</vUnCom><vProd>0.15</vProd><cEANTrib>SEM GTIN</cEANTrib><uTrib>UN</uTrib><qTrib>1.0000</qTrib><vUnTrib>0.1500000000</vUnTrib><indTot>1</indTot></prod><imposto><ICMS><ICMS00><orig>0</orig><CST>00</CST><modBC>2</modBC><vBC>0.15</vBC><pICMS>12.0000</pICMS><vICMS>0.02</vICMS></ICMS00></ICMS><IPI><cEnq>999</cEnq><IPINT><CST>53</CST></IPINT></IPI><PIS><PISOutr><CST>49</CST><vBC>0.00</vBC><pPIS>0.0000</pPIS>...

Alguém tem ideia do que pode ser isso? Nessa função percebi que alguns parâmetros estão passando vazio e retorna nada no Result.

Usando o "winCrypt" também dá o mesmo problema nessa dll "ntdll.dll",

mas depurando a sequência de mensagens é diferente cai na dll "libxml2.dll" antes de ir para "ntdll.dll"

 

Alguém tem alguma ideia para  descobrir porquê desse bug que está dando. Porque eu não

consegui reproduzir esse problema na versão demonstração, em vista que nosso projeto tem vários detalhes...?

Já que está sendo pago alguém deveria estar dando suporte...

 

[Daniel Simoes]

Experimente copiar Todas as DLLs da LibXML2 na mesma pasta do seu .EXE

http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/LibXml2/x86/

[Próton Sistemas]

Estou com esse mesmo problema, porém a situação só ocorre em um cliente em específico. Lá ocorre em diferentes versões do Windows também e está usando openSSL, mas já fiz o teste com WinCrypt e o mesmo problema continua. Só não testei ainda usar CAPICOM, mas me sinto desestimulado em fazer esse teste, já que essa opção foi descontinuada.

Houve algum avanço neste tópico?

Rafael 

[Daniel Simoes]

Parece ser um problema na máquina ou certificado desse cliente...

[Juliomar Marchetti]

7 horas atrás, ProtonSistemas disse:

Estou com esse mesmo problema, porém a situação só ocorre em um cliente em específico. Lá ocorre em diferentes versões do Windows também e está usando openSSL, mas já fiz o teste com WinCrypt e o mesmo problema continua. Só não testei ainda usar CAPICOM, mas me sinto desestimulado em fazer esse teste, já que essa opção foi descontinuada.

Houve algum avanço neste tópico?

Rafael 

Que windows é? versão.

e as dll do openssl estão na versão 1.0 superior?

[Próton Sistemas]

8 horas atrás, Juliomar Marchetti disse:

Que windows é? versão.

e as dll do openssl estão na versão 1.0 superior?

Windows 7 SP1 e a DLL openSSL na versão 1.0 superior. Vou fazer o teste com CAPICOM, pois mesmo depois do Update do Windows nada resolveu.

Mais uma coisa: a aplicação tem dois processos. Um na thread principal que faz as emissões das NFCe e cancelamentos e tem uma thread que faz inutilizações, cancelamentos por substituição.. Ou seja, pode haver concomitância entre esses processos. Vi que o usuário que iniciou essa thread chama o componente numa thread. Será que isso pode ter relação com o problema?

Att.

Rafael

[Próton Sistemas]

Depois que atualizou o Windows a aplicação capturou o log abaixo:

Access violation at address 770D1D3A in module 'ntdll.dll'. Write of address 00000014
Messagem: Error on call to Winsock2 library function shutdown: O aplicativo não chamou WSAStartup ou WSAStartup falhou

Sendo que antes isso não era capturado pela aplicação. Era um erro que aparentemente não caia na pilha de exceção da aplicação.

Att.

Rafael

[Juliomar Marchetti]

1 hora atrás, ProtonSistemas disse:

Windows 7 SP1 e a DLL openSSL na versão 1.0 superior. Vou fazer o teste com CAPICOM, pois mesmo depois do Update do Windows nada resolveu.

Mais uma coisa: a aplicação tem dois processos. Um na thread principal que faz as emissões das NFCe e cancelamentos e tem uma thread que faz inutilizações, cancelamentos por substituição.. Ou seja, pode haver concomitância entre esses processos. Vi que o usuário que iniciou essa thread chama o componente numa thread. Será que isso pode ter relação com o problema?

Att.

Rafael

Pode

lembre-se tudo o que tu vai fazer se criou uma thread tem que pertencer a ela senão ele vai usar da principal e vice versa e será o mesmo

então se tu tem uma thread dentro dela tem que ter instancia do componente e configuração fora que podem estar acessando ao mesmo tempo o certificado digital

[Próton Sistemas]

6 minutos atrás, Juliomar Marchetti disse:

Pode

lembre-se tudo o que tu vai fazer se criou uma thread tem que pertencer a ela senão ele vai usar da principal e vice versa e será o mesmo

então se tu tem uma thread dentro dela tem que ter instancia do componente e configuração fora que podem estar acessando ao mesmo tempo o certificado digital

No caso são instâncias diferentes do componente ACBrNFe, cada processo usa a sua, mas de fato eu não controlo o acesso ao certificado entre os dois processos. Uma coisa importante é que isso parece ter alguma relação com uma atualização dos componentes do ACBr que foi realizada um tempo atrás. O cliente passou a reclamar do problema depois que recebeu essa versão.

No caso eu preciso controlar o acesso ao certificado pelas threads? Teria que pensar em uma forma eficiente de checar o bloqueio do recurso caso isso seja o problema, pois é o componente do ACBr que faz uso do certificado.

Att

Rafael

[Daniel Simoes]

Verifique se não tem relação, com a chamada de CoInitialize

 

[Próton Sistemas]

7 minutos atrás, Daniel Simoes disse:

Verifique se não tem relação, com a chamada de CoInitialize

 

Acredito que não, pois todas as chamadas feita pela thread usam Co(Un)Initialize num try/finally e a thread principal não precisa, pois o CoInitialize é chamado automaticamente. De qualquer forma, se eu removo o CoInitialize não ocorre a execução dos métodos do ACBr com o erro justamente informado que precisa usar CoInitialize.

Acabei de testar uma configuração da aplicação de funcionar somente OFFLINE que significa que a thread não roda em paralelo com a principal e a thread principal emite em contingência. Dessa forma o erro parou. Ao que parece tem algo conflitando mesmo entre os processos.

Saudações,

Rafael

[Juliomar Marchetti]

1 hora atrás, ProtonSistemas disse:

No caso são instâncias diferentes do componente ACBrNFe, cada processo usa a sua, mas de fato eu não controlo o acesso ao certificado entre os dois processos. Uma coisa importante é que isso parece ter alguma relação com uma atualização dos componentes do ACBr que foi realizada um tempo atrás. O cliente passou a reclamar do problema depois que recebeu essa versão.

No caso eu preciso controlar o acesso ao certificado pelas threads? Teria que pensar em uma forma eficiente de checar o bloqueio do recurso caso isso seja o problema, pois é o componente do ACBr que faz uso do certificado.

Att

Rafael

Olha não creio que seja problema de atualização do ACBr senão estariamos com forum inundado de tópicos eo discord também.

sim pois é um arquivo e vai ter que ter um semafaro ou algo assim ou se tu carrega do banco dai não tem problema pois cada um vai carregar em separado. outra coisa é a questão do schemas

1 hora atrás, ProtonSistemas disse:

Acredito que não, pois todas as chamadas feita pela thread usam Co(Un)Initialize num try/finally e a thread principal não precisa, pois o CoInitialize é chamado automaticamente. De qualquer forma, se eu removo o CoInitialize não ocorre a execução dos métodos do ACBr com o erro justamente informado que precisa usar CoInitialize.

Acabei de testar uma configuração da aplicação de funcionar somente OFFLINE que significa que a thread não roda em paralelo com a principal e a thread principal emite em contingência. Dessa forma o erro parou. Ao que parece tem algo conflitando mesmo entre os processos.

Saudações,

Rafael

Com toda a certeza é. e estão acessando os mesmos recursos ao mesmo tempo.

olha o certificado e também os schemas.

[Próton Sistemas]

10 minutos atrás, Juliomar Marchetti disse:

Olha não creio que seja problema de atualização do ACBr senão estariamos com forum inundado de tópicos eo discord também.

sim pois é um arquivo e vai ter que ter um semafaro ou algo assim ou se tu carrega do banco dai não tem problema pois cada um vai carregar em separado. outra coisa é a questão do schemas

Com toda a certeza é. e estão acessando os mesmos recursos ao mesmo tempo.

olha o certificado e também os schemas.

Os schemas e o certificado ficam numa mesma pasta e os dois processos compartilhavam mesmo antes. Ainda acho curioso antes não ocorrer o problema e o mesmo ficar tão crítico depois de uma atualização de versão no cliente (na qual atualizei ACBr e versão do produto).

Uma atualização: peguei duas máquinas com Win7, mudei para WinCrypt e deixai UAC desligado (nível mínimo) e o problema parou de ocorrer pelo menos nos testes iniciais. Vou acompanhar mais.

Att.

Rafael